Two-tier gate: a fast tier judges every push in five minutes, the full gate runs once on land #1200

This adds the fast tier and its selection logic. The forge-side land flow from the issue is not wired up yet.

What changed

• src/checks/tiers.ts (new) picks the fast set from a diff. A test is in if it is:

- changed in the diff; - named for a changed source file (src/snapshot/store.ts pulls in test/snapshot-store.test.ts and test/snapshot.test.ts); - importing a changed file within two hops; - listed in a learned set; - recorded in test-times.json at under 1 s.

It also holds the checks-line words ("fast tier: green in 3m40s · full gate runs on land") and landVerdict. That decides whether a red full gate reopens the pull, names the red tests and teaches their files to the fast set.

• scripts/test-shards.ts takes --tier fast --diff <base>..<head> and an optional --learned a,b. The refs are validated, and the run prints why each file was picked and warns when the plan is over the 5-minute budget.
• forge.json declares check.fast as well as check.run, and parseCheck accepts fast and full. full defaults to run, and fast is null when it isn't declared.
• .forgejo/workflows/check.yml runs the fast tier on pull requests, still sharded. Pushes to main keep the full gate; I did not touch the tag build.
• test/check-tiers.test.ts is in the gate. It covers the snapshot-store include, the web-phone exclude, the import-hop limit, the checks-line words, the red-on-land reopen, and the manifest fields.

What I left out

• The forge's own check service doesn't act on any of this yet. It still runs check.run on every push, and nothing yet runs the full gate on land, reopens the pull, or stores the learned tests per pull. src/checks/service.ts and the merge path are where that goes, and tiers.ts is shaped to be called from there.
• The pull page's checks line is unchanged; tierLine is not rendered anywhere yet.
• origin/main..HEAD in the forge.json fast command assumes the checkout has origin/main. The forge's check cell should pass the pull's real base.
• A test missing from test-times.json is not known to be quick, so it runs only when the diff picks it. Most files have no recorded time today (a re-record would fix that).

Verification

• tsc is clean, and check-tiers and check-list pass.
• test/checks.test.ts has 3 failures here, and they fail the same way without my change.
• I did not run the full gate.

Try it Run bun scripts/test-shards.ts --tier fast --diff HEAD~1..HEAD.

Closes #1198

The forge's checks service now runs the two tiers: fast on every pull push, and full once on land. tiers.ts is untouched. tsc --noEmit is clean and test/check-tiers.test.ts passes (14 tests). I could not run test/checks.test.ts, test/crew.test.ts or test/pulls.test.ts here. This sandbox refuses unix-socket listens, and the same 4 failures show up on main's code with my changes stashed. test/autonomy.test.ts and test/crew-direction-autonomy.test.ts ran with the rest and showed no failure of their own.

• Fast tier on a pull's check: src/checks/service.ts now runs manifest.fast for a pull's check. It finds the fork point, the merge-base of the base tip and the head. It gives the check's clone a tiny git repo holding just that commit and the head (src/checks/history.ts), because the exported tree has no history. The command gets FORGE_CHECK_BASE, and forge.json's fast command is now --diff $FORGE_CHECK_BASE..HEAD --learned "$FORGE_CHECK_LEARNED". A repository with no fast still runs run. Branch pushes also still run run.
• Full tier on land: landIfGreen calls gateOnLand (src/checks/landing.ts) after the review and wall checks, before the ship decision and the merge. It builds the merge of the pull with its base and runs manifest.full on it through a new checks.gate().

- Red comments on the pull with landVerdict's words, records a land/red decision keyed to the head and base, and doesn't land. It isn't retried until the head or base moves. - The failed test files are saved per pull (src/checks/learned.ts) and handed to the pull's next fast run as FORGE_CHECK_LEARNED. - A repository without fast skips the gate, since its run already passed on this head. So does a forge with no checks service.

• Checks line: the pull page appends tierLine(...) to the checks line when the head's forge.json declares a fast tier and a check run exists.
• Service tests: test/check-tiers.test.ts gains three cases:

- The fast command runs for a pull check with FORGE_CHECK_BASE set to the fork point. The diff shows only the pull's file, though main moved on. - The full command runs through gate(). - A red full gate names its tests and teaches the pull, and gateOnLand returns the reopen verdict.

What I left out:

• The full gate on land writes no run row and has no log page. Its output is only parsed for failures.
• The tier line doesn't show the full gate's progress on land.
• A pull page test for the tier line is missing. The page needs a live server, which this sandbox can't start.

I couldn't see anywhere this pull needed to disagree with the review.

Reviewed the wiring (42b509db): service runs the fast tier with FORGE_CHECK_BASE from the fork point, the full tier on the merge before landing, red reopens and teaches; it does what #1198 asks. Carried upstream as Forgejo trevato-apps/forge #30 (both commits as written) because this forge's lane would take ten hours to judge it. Ships as 0.7.67; this pull closes as done upstream when the fork takes the update.

No code changes in this round, so I pushed nothing. The review asks for no change to 42b509d.

• What the pull does: The fast tier runs on each push with FORGE_CHECK_BASE set to the fork point. The full tier runs once on the merge before landing. A red result reopens the pull and teaches. The tier line shows on the pull page.
• Why it closes: @trevato carried both commits as written to Forgejo trevato-apps/forge #30, because this forge's lane would take ten hours to judge them. They ship as 0.7.67, and this pull closes as done upstream when the fork takes the update.
• Disagreement: None.
• Left out, unchanged: Nothing new.
• Try it: Push to a branch with a check in forge.json and read the tier line on the pull page.