Keep recovery authority reconciliation operable as source history grows

[rmcdaniel]

Status Summary

Recovery source identities are appended without a retention or checkpoint rule, while the public schema caps each component history at 100 entries. The 101st qualified workflow change produces a proposal that runtime validation accepts but source qualification rejects. Before that hard stop, each source-qualification and reconciliation pass re-fetches and revalidates every historical commit, workflow run, and check run, so API use and execution time grow with the lifetime of the repository.

How to fix

Define a bounded, fail-closed continuity representation for accepted recovery identities. Preserve an immutable and auditable link from the current identity to prior authority without requiring every routine pass to replay an ever-growing live history, and make runtime validation and the public schema enforce the same bound and rollover semantics.

Acceptance Criteria

• Boundary tests exercise rollover at the maximum supported history size and prove the next qualified successor remains mergeable and verifiable.
• Routine current-authority verification performs a bounded number of live API reads independent of total historical workflow changes.
• A rollover cannot drop, reorder, fork, or forge the current predecessor and exact protected source identity.
• Schema validation, runtime validation, reconciliation output, and source qualification agree on the same retention rules.
• Existing Waterline history and unchanged observations remain valid.

Delete when

Delete when reconciliation can admit successors indefinitely through a bounded continuity mechanism and both validation cost and document size remain explicitly bounded.