Add audit command and outbox foundations

docs/AUDIT_TRACE_CONTEXT.md

@@ -80,3 +80,26 @@ acceptance events should include:
 
 This keeps admin UI timelines, audit exports, and rollback diagnostics aligned
 without coupling modules to the audit table implementation.
+
+## Commands, Events, And Outbox Delivery
+
+Commands and events are separate concepts:
+
+- Commands are imperative requests to do work, for example `retention.run` or
+  `module.install`. They use `govoplan_audit.backend.commands.AuditCommand`
+  and `CommandBus`.
+- Events are completed facts, for example `tenant.created` or
+  `retention_policy.run`. They use the core `PlatformEvent` envelope and may
+  be written to the audit outbox before delivery.
+
+`govoplan_audit.backend.outbox.SqlAuditOutbox` persists platform events in
+`audit_outbox_events`. Dispatchers can later call
+`dispatch_pending_platform_events()` to publish pending events and record retry
+state. The outbox payload stores the full governed event envelope:
+correlation/causation ids, actor, tenant, subject, resource, classification,
+module id, event id, type, and payload.
+
+Application code should enqueue or publish facts only after the state change
+they describe is known. Long-running operators and installers should model
+requested work as commands first, then emit facts as events as each step
+completes.