Prevent stale PR-head rewinds during current-main integration

[leehack]

Incident

During the approved PR #434 integration on 2026-08-23, GitHub recorded a head_ref_force_pushed event that rewound the normally integrated head aa785dd to stale head 62c38d0. The active merge and QA tasks did not perform that write. Concurrency then cancelled exact-head CI. The manager detected the rewind, restored current main normally at bebae84, reran full CI and independent review, and only then merged.

Required safety contract

• Identify every automation or task capable of writing an open PR branch.
• Prohibit force-push and stale-head restoration in those paths.
• Require expected-head compare-and-swap protection for every PR-branch update.
• Reject a head transition that is not a descendant of the last observed integrated head unless an explicit recovery is approved.
• Treat unexpected head rewinds as a hard readiness hold that cancels prior CI and review evidence.
• Record the writer, before/after heads, timeline event, and recovery evidence in the handoff.
• Add durable regression coverage or static workflow checks where feasible.

Acceptance criteria

• The writer responsible for the fix: restore a self-consistent chat app lockfile SDK bound #434 rewind is identified or conclusively bounded.
• No authorized task can force-push or overwrite a newer PR head with stale local state.
• A simulated concurrent stale writer fails without changing the remote head.
• The project-manager checklist requires fresh CI, review threads, and independent QA after any unexpected head transition.

This issue tracks process and automation safety only; PR #434 itself was restored, requalified, and merged with the reviewed tree.