Explore: stream the audit log to a SIEM, and whether that is its own module

Exploration. What would it take to stream the audit log somewhere else, and is that a module.

## Why this comes up

Audit is solid now. `AuditEvent` is tenant-isolated (#647 fixed a hole where any tenant admin could read every tenant's log), it records who did what, and `GET /api/audit` serves it.

It only lives here. An enterprise evaluating a self-hosted system asks, usually in the second week of a security review, whether its audit trail reaches their SIEM. Splunk, Sentinel, Elastic, Datadog. The answer today is "write a poller against our API", which is the answer that loses the evaluation.

This is the same shape as #688, the messaging module: something already happens in process and the question is how it durably leaves the process.

## Questions

**1. Push or pull?**
A pull surface is a cursor endpoint: `GET /api/audit?since=` with a stable ordering, which the delivery API does not have either (#560, #666 are the same shape for content). A push surface is the broker from #688 with an `audit.*` topic. Pull is less machinery and works through a firewall a customer controls. Push is what an event-driven estate expects. They are not exclusive.

**2. Is the audit log an event stream or a document table?**
Determines whether a cursor is possible at all. If a consumer cannot resume exactly where it stopped, this is a reporting feature rather than an audit feed, and an auditor will say so.

**3. Does this overlap #688 enough to be one thing?**
Content events and audit events are both "something happened, tell another system, durably, exactly once enough". Two modules that solve that twice would be a mistake. Decide whether audit is a topic on the same transport or its own package.

**4. What is on the wire?**
Audit records who did what. Sensitivity rules apply on the way out of the REST endpoint. Whatever leaves for a SIEM has to go through the same masking, and there must not be a second copy of those rules, which is the discipline `ContentChangeListener` already keeps by reusing `PublicDelivery.ToPublic`.

**5. Retention and back pressure.**
If a SIEM is unreachable for a day, what happens? The webhook delivery retention service and #527 (purge dead letters) are the existing answers to that shape of question.

## Done when

A decision on push, pull or both, and whether this is part of #688 or its own package. No code required to close this.

Related: #688, #560, #666, #527.

Start with AuditEvent and GET /api/audit, then compare the delivery API questions in #560 and #666 with the messaging design in #688. Read ContentChangeListener, PublicDelivery.ToPublic, and the webhook delivery retention service, plus #527, to assess masking and back pressure. Done means documenting a decision on push, pull, or both, and whether audit belongs in #688 or its own package.

Written by the indexing model from the issue text.