ref-update event v1 rollout: lag_origin is unverifiable to v0 receivers #582

#580 bumps the signed ref-update event format from version 0 to version 1, adding lag_origin to the signed field set.

Why this needs a rollout decision

A v1 event reaching a node running pre-v1 code deserializes with the unknown v/lag_origin fields dropped, so the signature verifies against bytes that differ from what the publisher signed. The event is rejected as a signature failure, which reads as a forgery in logs and counters, not as "peer too new." The version gate added in #580 only protects receivers running the new build; deployed old builds cannot benefit from it.

Consequence: once a v1-emitting node deploys, every un-upgraded peer rejects its ref-updates until that peer upgrades. On a mixed fleet this partitions ref-update flow and looks like an attack.

Safe rollout shape

Ingest-before-emit ordering: all peers must run the v1-capable build (so they can verify and admit v1 events) before any node emits v1. If the deployed fleet cannot be upgraded in that order, the emit side needs to be gated (config flag or fleet check) rather than unconditional.

Request

Confirm the rollout policy for this version bump: either the fleet is small/controlled enough to upgrade in order and the issue can close, or the emit should be gated until the fleet is known capable.