Audit log: operator-configurable retention period

In #10042 we are hard-coding (ish, it's a Nexus config option) a retention period of 90 days for the audit log in order to avoid customers being surprised by a cleanup before they have a chance to fetch everything they want to fetch. Depending on how the system is used, the audit log can vary a lot in size. On colo we have 5M rows total (385k in the past week) with a size of about 26MB per 100k rows. On dogfood we have only about 200k rows total, with a size of about 45MB per 100k rows (colo had a very high proportion of login_saml entries, which are smaller because they don't have an actor ID).

On top of the size variation, depending on how customers fetch the log and dump it in an external system, they may be totally fine with a retention period as short as a week or two. An operator-configurable retention period (probably a singleton DB table with a single row) would let operators set this if necessary. On the other hand, a few GB of space for this table should be no big deal. I'm sure we have worse tables.

Ultimately I'm not sure if we need this. It's better to avoid adding settings if possible. Another approach would be to just shorten the retention period to 30 days for everyone if we become confident that's enough time.

Start with issue #10042 and review the existing 90-day audit-log retention and Nexus configuration described there. Decide whether to add an operator-configurable retention period backed by a singleton database row or shorten the default for everyone. Done means a chosen approach with defined retention behavior and operator-facing configuration, or a documented rationale for not adding the setting.