fix: make push verification recoverable after a force-push to main

[chtnnh]

Problem

The push verification workflow uses github.event.before as the start of the landed-history walk. After an intentional force-push to main, that SHA may no longer be reachable from the fetched refs, so the workflow fails with:

know-code: --from <sha> is not a commit in this repository

Failing closed is the correct safety behavior: silently skipping verification would weaken the guarantee. The problem is operational clarity and recovery, not acceptance of rewritten history.

Scope

Detect and explain the forced-history case explicitly, while keeping the normal push path unchanged and fail-closed. Provide a narrow, documented recovery path for maintainers who intentionally rewrote main.

Acceptance criteria

• A missing or non-ancestor github.event.before is identified as a possible history rewrite rather than reported only as an unknown commit.
• The workflow remains fail-closed; it must not silently treat a force-push as verified.
• Maintainers receive an actionable recovery instruction or deliberately invoked verification path.
• Normal fast-forward pushes retain the existing stacked-run verification behavior.
• Tests cover a missing --from commit and a non-ancestor baseline.

Priority

Deferred: force-pushing protected main is intentionally uncommon. Address before relying on the push workflow as the only verification signal for rewritten base-branch history.