audit: record which token enqueued what

Tokens are named, scoped, namespace-bound and expiring. Once a call is authorised, nothing
records that it happened. There is no answer to "which token enqueued this job", "who cancelled
it", or "what did the token we just revoked do while it was valid".

For a queue that only ran inside one application that was fine — the application's own logs were
the audit trail. A network door with third-party credentials is a different thing, and the
question gets asked for the first time on the day someone needs it answered retroactively.

Record, per authorised mutating call: token id (never the token or its digest), principal name,
namespace, operation, target (job id, queue, worker), timestamp, and outcome.

Decisions the issue needs to settle before implementation:

• Where it lands. A storage table means a three-backend parity obligation and a retention
  policy, and it puts audit writes on the request path. A structured log stream means it is
  someone else's retention problem and it disappears on a pod restart. Pick deliberately and
  write down why.
• Reads or only writes. Auditing every read is expensive and mostly noise; auditing none of
  them cannot answer "what did that token see".
• Retention. If it is a table, it grows forever unless the retention machinery covers it.
• Attribution on the job itself. A jobs column naming the submitting token answers the
  most-asked question cheaply, without a log search. It is also a schema change with the usual
  cost — a new field is ~40 literal sites — so it is a separate decision from the log.

No secret material in the record, ever.

No files, tests, or entry points are named in the issue. Start by resolving the storage, read coverage, retention, and job-attribution decisions; done means the chosen design records the specified attribution and outcome without secret material, with its tradeoffs documented.