Reconcile retained fork retries after uncertain durable acknowledgement #779

1. Background Context

The trusted local host retains native AuthorOnly forks for the observation-bound driver. Its private runtime/provenance fork is published only after the topology append returns success. This completes the local retained-fork outcome of #728; the broader historical topology contract is #605.

2. Problem Description

An injected CommitMarkerSynced error occurs after a fork transaction is durable. The runtime still has no fork, so retry appends it again. Actual Docker RED observes four transactions instead of the expected three; duplicate topology prevents lawful reopening.

2b. Proposed Solution

Reconcile writer permission and validate the committed fork records before acknowledging a retry or admitting a new label. Recover every pending fork at its original native basis on private clones, check existing topology bindings, and publish only after the complete set validates. Pending forks count before capacity admission.

2c. Alternatives considered and rejected

Blind retry: duplicates durable records.
Only reconcile the requested label: permits other pending forks to evade the capacity limit.
Accept duplicate records during recovery: weakens the retained-history contract.

2d. Acceptance Criteria

• All three append fault boundaries retry and reopen with exactly one retained fork.
• Parent advancement preserves the original fork tick and commit identity.
• A different label reconciles every pending fork before fresh admission.
• An unacknowledged 64th fork blocks a 65th; exact retry at capacity resolves the original head.
• Invalid or duplicate records remain refusals, without publishing partial reconstructed topology.

2e. Test Plan

Golden: existing native retained-fork/recovery witness.
Edges: parent advancement, different label, 63 visible plus one pending fork.
Known failure modes: AppendFrame, FlushCommit and CommitMarkerSynced fault injection, exact retry and reopening.
Fuzz and stress: bounded fixed fixtures, at most 64 forks; no unbounded campaign or physical power-loss claim.

3. Prerequisites

• Retain observation-bound executable requests across host loss #727: supplies the native observation/request protocol used by the retained-alternative driver.
  The already merged perf(wal): derive operation contexts from validated committed prefixes #778 cache is an accepted sequencing predecessor, not a separate correctness prerequisite for strand retention.

4. Scope

In: trusted-local fixed-profile retained forks, validated pending topology, atomic live reconciliation, retry/capacity/reopen witnesses and canonical hosting documentation.
Out: authenticated service policy, durable strand drop, braid/merge/promotion, application/editor nouns, production Keep adoption and old duplicated-history migration.

5. Why now

#728 must leave main usable after an uncertain durable acknowledgement before it can land.

6. Risks

Replaying at a newer parent basis or publishing only part of pending topology. Validate original records and native receipt bindings on clones before publication; retain duplicate refusal.

7. Definition of Done

#728 passes guarded current-head witnesses, relevant surrounding checks, hosted CI and independent review, then its main integration commit is linked here.

8. Stakeholders

Echo trusted-host maintainers and local retained-alternative consumers.

9. Related Issues

PR #728; historical #605; merged #727 and #778; parent integration tracking #722. Independent proposal feedback is retained in Reader receipt 14dc9b32-5ffe-471c-8fe6-4c4841078aff.