A pull's check tier comes from the base branch's forge.json: the 43 pulls opened before #1200 still run the full gate on every push #1275

0.7.67 is live with the two-tier gate and #1200 landed on this fork at 17:12Z, so forge.json on main declares check.fast. The first check after the roll still ran FORGE_CHECK_SHARDS=1 bun scripts/test-shards.ts --timeout 60000 --gate: src/checks/service.ts reads the manifest from the commit it checks, and every open pull was branched before main had a fast tier. The 43 queued checks will each take 20 minutes until their branches are rebased, which the crew does not do.

A pull should not choose its own gate either way: a pull that edits forge.json to weaken check.run would check itself with the weaker command.

Done looks like:

• [ ] For a pull's check, check.fast and check.full (and timeout) are read from the base branch's forge.json at the pull's base oid; install and run for a plain branch push stay as they are (the branch's own).
• [ ] The check log says which manifest it used in one line: tier fast from main@3bc88de.
• [ ] test/check-tiers.test.ts: a pull whose head lacks check.fast but whose base has it runs the fast tier; a pull that edits check.fast in its own head is still checked with the base's.

Evidence: pod process list at 17:12Z, one minute after the 0.7.67 roll.

Parked by the crew: the check failed ("checks > an open pull whose head was never checked is checked when the service boots") and the decider saw no point in another try (pull #1276 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.