Group the home's per-app reads (Later gate, per-repo issue counts) so a cold / is fast #12311

This only partly does what the issue asked. The held line and nextUp now read less, but a cold / under bun test still costs about 310 statements, because that cost is not where the issue put it. I did not touch SLOW in scripts/gate.ts, since it is already empty. tsc, scripts/gate.ts and the tests I ran pass; the snappy budget test failed until I set 320, and it passes at that figure.

What was already true on main

• On the request's own connection, a cold / on the 12-app fixture is about 50 statements and about 13 ms p50. A worker now reads the lanes picture off-thread.
• The 316 figure comes from bun test, where NODE_ENV=test makes the lanes picture read inline on the request's connection. That is nextUp per autonomous app, not pillarsOf per app and not per-repo issue counts.

What changed

• reposWithGateTitle in src/core/pillars.ts is one grouped read of the repos with an open Later gate: issue. The held line (src/web/studio/held.ts) now calls gateHold only for those. Before, it called it for every app with any pillar-titled issue. reposWithUmbrellas is now built on a shared helper; its behaviour is the same.
• nextUp (src/core/next_up.ts) reads an app's pillars once and passes them to repoGraph. It used to read them twice. That is the whole drop, 316 to 310.
• A test in test/pillars.test.ts covers reposWithGateTitle.
• COLD_SQL.homeOwner in test/snappy.test.ts goes from 330 to 320, with the comment rewritten to say why the figure is what it is.

What I did not do

• Grouping nextUp's roughly 30 reads per app across all apps is a larger refactor, and it buys nothing in production. I did not start it. It would be the way to bring the 310 figure down.
• I did not tighten the budget to about 50, because under bun test the inline picture cannot reach it.

How to try it: open / signed in as someone who owns apps with a Later gate. Each gate still shows in the held line.

Tests run:

• test/snappy.test.ts, test/pillars.test.ts
• test/boards-held.test.ts, test/map-held.test.ts, test/plan-held.test.ts, test/held-posts.test.ts
• the next-*, asks-rank, crew-ranked-pick, mcp-next-up and forks-ranking tests

scripts/fast.ts called the diff too broad to name, so I picked these myself.

🤖 Generated with Claude Code

The check failed on one comment line over 100 columns at src/core/pillars.ts:475, above reposTitled. I rewrapped it into a three-line block comment and pushed it. The wording is unchanged and no code changed.

bun scripts/gate.ts and bun x tsc --noEmit both pass locally. I did not run any tests, because the change is a comment only. The forge's own check will run on this push.

bun scripts/gate.ts checks the lines the branch adds in its commits, so it kept reporting the old line until I committed the fix.

I found no failure caused by this change. I merged current main into the branch and pushed it so the check re-runs against it.

• Pull's own tests: test/snappy.test.ts, test/pillars.test.ts, test/did-you-mean.test.ts and test/tui-crawlers.test.ts pass locally. The last two are suites the check reported as failing.
• Fail on unmodified main: five of the reported failures fail the same way on a clean checkout of origin/main, none of them in files this change touches:

- spawn-pipes - spawn-sites - mcp-table - spawn-in-process-visible - the did-you-mean 404 query-count test

• Not reproduced:

- The over-budget /map and / budget test is not among the suites I ran here. - The tui-crawlers "shows the share" failure passes locally. The check said it fails only beside other tests and it had no shard-mates, so it is probably a flake. - I did not run the terminal's-shift test or the hosted-forges mount test on the merged branch.

• Checks run: bun scripts/gate.ts and bun x tsc --noEmit pass on the merged branch.

If those five still fail on the next check, main is red for them and needs its own fix.