ci: guard the compatibility epoch against silent same-number merges

[yihanzhu]

Summary

Two branches that bump RUNTIME_HOST_COMPATIBILITY_EPOCH write the same text to the same line, so git's three-way merge resolves them without a conflict and two incompatible protocols end up advertising one epoch (#3313). This adds the interim merge-base guard from that issue: a Node-only CI step that runs on the PR merge result and fails when anything under packages/runtime-host/src/protocol/ changed while the epoch still equals the merge base's, or when the epoch moves backward (a revert must bump forward, not restore the old number).

The derive-the-epoch-from-the-contract question stays open — per the issue that decision belongs on the dev list, so this PR refs rather than closes it.

Refs #3313

Review focus

• The guard compares the merge result against pull_request.base.sha. After a sibling protocol change lands on main with the same epoch text, the silently merged tree still carries the base's epoch, so the second PR goes red on its next run — the case that currently has no guard at all. It still cannot see a sibling branch before one lands, and a stale green check stays green until the PR is updated; both limits are named in the issue.
• The guard is coarse by design, matching the issue's spec: comment-only edits under protocol/ also demand a bump. Running it over history, it would have flagged refactor(runtime-host): retire client surface identity plumbing #3277 and refactor: retire 'fake' from the live backend surface #3249 (protocol-tolerance changes that did not bump). Notably, the open refactor: drop the unread backend field from Automation templates #3334 trips it for the same reason — I can bump the epoch there if you judge that change epoch-worthy (a new Host emitting templates without backend breaks older clients whose decoder lists the key as required), or that stays the accepted false-positive class.

Verification

• node --test scripts/protocol-epoch-check.test.mjs: 7 pass (declaration parsing incl. a live-file pin, and the full verdict matrix)
• Real-history exercises: --base a6f33c952^ --head a6f33c952 (refactor(runtime-host): retire client surface identity plumbing #3277, protocol changed without bump) fails with the rebase-and-bump message; --base fd9ad4baa^ --head fd9ad4baa (feat(core,runtime,desktop): add Fast mode for OpenAI Responses relays #3309's 27→28) passes; this branch vs origin/main passes with "no protocol changes"
• Workflow policy suites, CI planner tests, root format:check and lint pass

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code (Fable 5) — implementation and tests, under my direction and review. The commit carries a Generated-by trailer.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — CI newly fails PRs that change protocol files without moving the epoch past the merge base's value

🤖 Generated with Claude Code