Reconcile provable legacy workflow revisions

[loganj]

🤖 I’m Larry, and this migration preserves workflow history without pretending the relay knows more than it does.

Summary

Legacy workflows can now gain an exact revision pointer when the relay can prove that the retained signed workflow definition is the source of the currently stored workflow. Rows that cannot be proven remain unchanged and continue through the existing compatibility fallback. Reconciliation supports the historical channel-less database shape as well as current channel-scoped storage, but always requires the signed event’s channel tag to match.

Historical workflow runs are intentionally never backfilled from current workflow state: the current definition cannot establish which revision an earlier run executed. The final bind also requires the validated workflow snapshot to remain unchanged, preventing an older relay binary from rewriting a workflow during rolling deployment and receiving stale provenance.

Related issue

Stacked on #6960. No separate issue found.

Testing

Validated exact commit dbe2b67af88bd1a68f92d257b31d9d91406902b0 on Blox workstation larry-buzz-workflow-legacy-v4-fix:

• cargo fmt --all -- --check
• migrated-Postgres end-to-end test proving a historical events.channel_id IS NULL definition is discovered and bound
• migrated-Postgres regression proving an intervening legacy-style workflow rewrite rejects the stale bind
• migrated-Postgres idempotence/run-preservation regression
• full buzz-db library suite: 112 passed, 203 infrastructure tests ignored
• full buzz-relay library suite with migrated Postgres configured: 924 passed, 50 infrastructure tests ignored
• cargo clippy -p buzz-db -p buzz-relay --all-targets -- -D warnings

[loganj]

🤖 I’m Larry. This automatic-backfill approach is retired and must not merge.

Review at b064beb5c39a8ea52c1d43565ddcace10f780ed6 established two failures of its exact-source contract:

• A pre-foundation writer can update the workflow after reconciliation binds E1 while preserving the newly added pointer. New runs then copy stale provenance.
• The pre-foundation writer commits workflow materialization independently before committing its signed-event transaction. If an equal-content E2 materialization commits but its event transaction fails, the surviving E1 head can match current JSON/hash without proving it sourced the current row. Snapshot fencing and draining old pods cannot recover missing historical evidence.

Legacy workflows and historical runs must retain the NULL compatibility fallback. No adoption UX is being substituted here. Any future owner-signed save establishes provenance prospectively and needs its own explicit semantics.

The draft and branch are preserved as review evidence, not as a merge candidate. The related foundation rollout also needs protection against legacy writers preserving pointers across subsequent definition updates.