Monitoring: tenant-labelled logs, metrics and an operational event stream

Logs and metrics cannot be read per tenant. Serilog writes to the console with `FromLogContext` and no tenant enrichment (`barakoCMS/Program.cs:15-32`). The only custom metric is the workflow projection lag gauge (`barakoCMS/Infrastructure/Health/WorkflowProjectionHealthCheck.cs:29`). There is no view of jobs or webhook deliveries by tenant, and the audit list is the only query by tenant and time.

### Why it matters

A school calls to say their enquiry form stopped sending at 3am. Answering that today means SSH, grepping container logs with no tenant field, and SQL against the runs table. An agency with twenty clients on one box cannot see which client is generating errors or load.

### The general concept

Every log event carries the tenant, request and actor. Metrics for requests, jobs, workflow runs and deliveries are labelled by tenant. An operational event stream (a job failed, a delivery dead-lettered, a workflow halted) is queryable by tenant and time through the API. This is the data underneath the incidents view in #893; #624 (correlation id), #696 (runner metrics), #691 (tracing) and #689 (audit to a SIEM) each cover a piece.

### Where it lives

Core: logging, metrics and diagnostics.

### Compatibility

Released surfaces are only added to. A new log property and metric labels change no stored data. Label cardinality grows with tenant count, so the tenant label is configurable for deployments with many tenants. No HTTP change beyond a new endpoint.

### Done when

- A log event written while handling a tenant's request carries its slug, and a test showing that fails before the change.
- Workflow run and job metrics have a tenant label.
- A failed delivery for one tenant can be listed through the API by tenant and time.

Found in the architecture sweep of 15 September 2026.

Start with logging in barakoCMS/Program.cs:15-32 and the workflow projection lag metric in barakoCMS/Infrastructure/Health/WorkflowProjectionHealthCheck.cs:29. Trace the existing audit tenant/time query and related issues before defining the cross-cutting design. Done means tenant-aware request logs, tenant-labelled workflow and job metrics, and an API query listing a tenant’s failed deliveries by time, with tests for the stated log behavior.

Written by the indexing model from the issue text.