feat(site-call-audit): relay Retry/Discard emit operator-identity audit rows

Additive RequestedBy on Retry/DiscardSiteCallRequest, plumbed from the Central UI.
On an Applied relay, SiteCallAuditActor emits one best-effort CachedResolve central
direct-write row (Submitted/Discarded) with the operator as Actor. Gated on an
injected ICentralAuditWriter (null in existing tests → no mirror read, unchanged);
the site remains the source of truth for the state change.

docs/requirements/Component-SiteCallAudit.md

@@ -107,6 +107,17 @@ applies the change and emits telemetry reflecting the new state; central never
 mutates the `SiteCalls` row directly. If the site is offline the command fails
 fast and the UI surfaces a "site unreachable" message.
 
+On a **successful** relay (the site acks `Applied`), `SiteCallAuditActor` emits
+one best-effort central **direct-write** audit row (`CachedResolve`, status
+`Submitted` for a Retry / `Discarded` for a Discard) carrying the authenticated
+operator as `Actor` and the `TrackedOperationId` as `CorrelationId` — recording
+*who asked*. The operator identity flows in on `RetrySiteCallRequest` /
+`DiscardSiteCallRequest` (`RequestedBy`, captured at the Central UI). This row
+only adds provenance: the **site remains the source of truth** for the state
+change itself, and central reads the stored `SiteCalls` row solely to enrich the
+audit row's channel/target (a benign read, never a mutation). Audit is
+best-effort — a writer fault never changes the relay outcome.
+
 Only `Parked` rows are operator-actionable. `Failed` rows offer no Retry or
 Discard: a permanent failure (e.g. HTTP 4xx) would simply fail again, and the
 error was already returned synchronously to the calling script — there is