feat: strengthen module contracts and shared WebUI runtime

docs/EVENTS_AND_AUDIT.md

@@ -8,25 +8,32 @@ module reactions, and operator diagnostics.
 
 ## Production Transport Decision
 
-The first production target is a **database outbox plus in-process immediate
-dispatch**:
+The production transport is a **transactional database outbox plus retrying
+dispatcher**:
 
 - Use `govoplan_core.core.events.PlatformEvent` for domain and platform events.
-- Use `EventBus` as the in-process dispatch contract for same-process module
-  reactions that are safe to run inline.
+- Call `emit_platform_event(session, event)` to bind event delivery to the
+  domain transaction.
+- The optional `platform.eventOutbox` capability persists events atomically.
+  The Audit module provides the current SQL implementation.
+- Without an outbox provider, Core publishes to `EventBus` only after the outer
+  transaction commits. This preserves reduced installations but is not durable
+  across process failure or multiple workers.
+- Use `EventBus` as the in-process dispatch contract for module reactions
+  invoked by the outbox dispatcher or for non-critical fallback reactions.
 - Use the shared `audit_event` / `audit_from_principal` helper for audited
-  module actions. The helper persists the audit row and immediately publishes a
+  module actions. The helper persists the audit row and transactionally emits a
   governed `PlatformEvent` whose `type` is the audit action.
 - Use `record_change` for module delta feeds. It persists the change-sequence
-  row and immediately publishes a generic module change event such as
+  row and transactionally emits a generic module change event such as
   `mail.profile.updated`.
-- Persist durable integration/workflow events through a database outbox before
-  acknowledging the state change that produced them.
-- Drain the outbox through a small dispatcher process. The dispatcher may call
-  in-process handlers in the same deployment first, but its storage contract is
-  database-backed.
+- Drain the outbox with the Celery `govoplan.events.dispatch_outbox` task on the
+  `events` queue. The periodic schedule also retries pending rows.
+- The dispatcher invokes Dataflow event ingestion when that capability is
+  active, then publishes to the process-local bus.
 - Treat Redis/Celery as worker/job infrastructure, not as the authoritative
-  first event transport. A Celery dispatcher can consume the outbox later.
+  first event transport. PostgreSQL remains authoritative until dispatch is
+  recorded.
 - Keep the dispatch implementation pluggable behind the `PlatformEvent`
   envelope so a future message broker can be added without changing event
   producers.
@@ -44,17 +51,18 @@ Event producers should write their domain state and outbox event in the same
 database transaction wherever possible. Handlers must be idempotent because the
 outbox dispatcher can retry after a crash or timeout.
 
-Recommended first outbox columns:
+The current outbox stores:
 
 - `event_id`, `event_type`, `module_id`
 - `correlation_id`, `causation_id`
-- `payload`, `occurred_at`
-- `available_at`, `attempt_count`, `claimed_at`, `claim_token`
-- `processed_at`, `last_error`
+- `classification`, serialized event `payload`
+- `status`, `attempts`, `next_attempt_at`
+- `dispatched_at`, `last_error`, timestamps
 
-Inline `EventBus` handlers are allowed only for non-critical local reactions.
-Anything that must survive process failure, restart, package update, or worker
-redeployment belongs in the outbox.
+Handlers must be idempotent: a worker may complete an external effect and fail
+before marking its outbox row dispatched. Anything that must survive process
+failure, restart, package update, or worker redeployment requires the outbox
+provider and dispatcher.
 
 ## Trace IDs