[EPIC E6] Build correlated GF step-event stream

[JorisHeadease]

Build the correlated step-event stream that drives the live GF viewer and provides the shared substrate for later inspection tooling.

Work items

• Add capture middleware around calls forwarded by the sandbox backend proxy.
• Generate one correlation ID per scenario run and an ordered sequence number per event.
• Emit the documented GF-labelled request, response, outcome, duration and timestamp fields.
• Allowlist captured headers and payload fields, and redact authorization headers, cookies, access tokens, credentials and other secrets before constructing or retaining an event.
• Deliver run-scoped events to the browser over SSE.
• Retain a bounded event window so a page refresh can restore the current run.
• Mask BSNs on shared deployments while allowing synthetic identifiers in local development.
• Drive per-patient demo locks from the same run lifecycle.
• Define reconnect and resume semantics independently of the frontend framework.

Acceptance criteria

• Events arrive in order and carry the correct run correlation ID.
• A refresh restores events within the retention window without replaying another run.
• Concurrent runs cannot observe each other's events.
• Shared deployments do not expose plaintext BSNs.
• No retained or streamed event contains authorization headers, cookies, access tokens, credentials or other secrets.
• The event schema contains no Datastar-specific fields or transport behavior and can be consumed unchanged by Preact + htm.

Refs #532
Refs #538

[JorisHeadease]

Two notes for the work item "Drive per-patient demo locks from the same run lifecycle".

Ownership changed in #554. A lock is now owned by the session that took it, derived from the session rather than a request field, so the run lifecycle has to acquire the lock while the practitioner's session is in scope. That is the natural case, since a run starts from a signed-in screen, but it does mean a background or unauthenticated trigger will not work.

Registry.Refresh exists and is currently called only from its own test. DESIGN §5.7 says a lock is "refreshed by activity, expiring on a TTL", and the refresh half is unimplemented, so today a lock simply expires 15 minutes after it is taken no matter what the presenter is doing. Wiring Refresh to run activity belongs with this work item.

Also relevant: a reset releases every lock, because ownership is session-bound and a reset drops all sessions, leaving locks nobody could release.