Core-wrapped audit for ops-plane mutations (ADR 0007).

mutation/4 runs the operation and writes the row from the operation's own return value. A call site therefore cannot forget to audit and cannot misreport the outcome, which is the whole point: the console's broadcast handler used to pass a hand-built {ok, SentTo} to its logger while the backing function had silently dropped every failed insert, so a half-delivered broadcast was recorded as a success.

The outcome contract

{ok, Succeeded, Failed} | {error, Reason}

Succeeded and Failed are lists of subjects the operation acted on - Failed entries carry their reason. A single-subject mutation is the one-element case, not a different contract, so nothing has to widen later when the first bulk endpoint lands. The stored outcome column is ok, partial or error, which is what makes "show me everything that did not fully succeed" an index scan rather than a jsonb parse.

{error, Reason} is the operation that never got as far as having subjects - a rejected parameter, a lost connection.

When the audit write itself fails

The audit never fails the operation. It runs after the mutation has already happened, so refusing the response cannot undo a ban or un-send a notification; it would only invite a retry that applies the change twice. A write-ahead row could fail closed, but it would record intent rather than outcome, and outcome - specifically partial failure - is what ADR 0007 asks for.

The cost of that choice is paid where it is cheapest: a failed insert is re-emitted at error level with every field the row would have carried, so the record degrades from queryable to greppable rather than disappearing. Nothing is dropped silently. A raise inside the audit path is caught for the same reason - the audit must not be able to fail an operation that already happened.

Erasure is the stated exception, and record_strict/4 is how it is taken. An erasure destroys the data it is about, so the row is the only surviving evidence the request was honoured; there is no degraded-but-still-there state for it to fall back to. record_strict/4 reports whether the insert landed so the caller can write it inside its own transaction and roll the erasure back when it did not. Nothing else should use it.

Successful writes are not also logged. The row is the record, and mirroring it into logs would double the retention surface holding player ids for no new information.

A mutation that raises is audited as an error and then re-raised with its original stacktrace. A crash is an outcome, and the plane should not be able to hide one by exploding.