Add durable Workshop delivery authority epochs

[dcellison]

Summary

• add a durable, typed authority epoch for the future Telegram conversation-finalization lane
• stamp new streaming-finalization requests atomically with the currently active epoch
• require workers to claim, recover, and settle work only for their exact still-active epoch
• add aggregate, non-secret authority readiness information to make install-status
• record the transitional boundary and its explicit retirement criteria in the Workshop implementation map

Why

The future Workshop delivery worker must not overlap ambiguously with the current direct Telegram delivery path. A restart-safe authority boundary is needed before any production cutover can be considered. Process-local flags are insufficient because they cannot distinguish work created under different authority periods or prevent a later worker from draining older work.

This PR establishes that boundary without activating it in production.

Durable contract

Schema version 14 adds:

• delivery_authority_epochs, with at most one active epoch for the conversation-finalization lane
• nullable delivery_outbox.authority_epoch_id, deliberately leaving historical rows unclassified
• indexes for exact-epoch due-work selection and per-binding ordering

Activation is transactional and idempotent across restarts and concurrent attempts. First activation fails closed if matching historical outbox work is unclassified; it never silently adopts those rows.

Atomic streaming finalization resolves the active epoch inside the same database transaction that records the canonical outbound message and delivery request. Callers cannot choose or inject an epoch.

The streaming-finalization worker now requires a typed epoch at construction and uses that exact epoch for:

• claims
• predecessor ordering
• expired-lease recovery
• targeted delivery execution
• terminal settlement

An inactive or different epoch cannot drain or complete the work.

Deactivation refuses non-terminal work. If the epoch contains terminal failures, including failures with uncertain-fragment evidence, an operator must explicitly acknowledge them before deactivation. The evidence remains durable after acknowledgement. A later activation creates a new epoch and cannot replay prior-epoch work.

Operator diagnostic

make install-status now includes one aggregate authority line reporting:

• active/inactive/not-ready state
• epoch and unclassified-work counts
• prior non-terminal, failed, uncertain, and unacknowledged counts
• active pending, leased, retrying, succeeded, failed, and uncertain counts

It does not expose epoch IDs, delivery IDs, lease IDs, worker IDs, Telegram identifiers, message content, or provider errors.

Production safety

This remains a production-unused foundation:

• installation does not activate an epoch
• startup does not activate an epoch
• no production worker is registered
• no handler or live Telegram route calls the new authority service
• current direct Telegram delivery remains authoritative

The implementation map requires a separate sixth cutover review before any production wiring is authorized.

Tests

• make check
• make typecheck
• .venv/bin/python -m pytest -q

Result: 5392 passed, 1 skipped

New contracts cover idempotent restart, concurrent activation, fail-closed inactive enqueue, internal epoch stamping, exact-epoch isolation, non-terminal deactivation refusal, explicit terminal-failure acknowledgement, rollback/reactivation without replay, unclassified historical work, and aggregate non-secret diagnostics.