Is your feature request related to a problem? Please describe.
Following up on a discussion it might make sense to separate tune options from audit tune options, as @cipherboy suggested:

auditing is one of those weird things where its cross-role really, tbh. A separate set of paths might make some sense; perhaps we could introduce a path like sys/mounts/:path/audit-tune which just has those two keys? Tuning I do agree, seems to mostly be the scope of a mount-level admin, but auditing seems to more broadly require collaboration between instance/auditing admins and the admins of individual plugins being SMEs and knowing what is safe to HMAC/non-HMAC.

Describe the solution you'd like
Have way to tune audit settings independently of the secrets tune settings, allowing different roles to manage those.

Describe alternatives you've considered
#474 was the starting point of the discussion which alternatively suggests removing some mountpoints from untunableMounts to allow tuning the audit settings in the first place. Doing #474 either by allowing to tune audit settings on sys and identity or removing those mountpoints from untunables solves my issue but the suggested approach of splitting the paths feels better as it allows more granular control where it is (imho) warranted.

Additional context
I personally feel like this change makes sense but at the same time it is a breaking change (it will break automation like Tofu) and I think it should be considered in the context of the bigger picture. Again, personally, I think this change is too substantial to be warranted doing alone and should rather be a part of a larger "package" that reworks auditing for example.

Imho #474 can be solved independently on this FR.