A repository's milestones page computes its plan under 50 ms: trevato/forge's `plan` phase is 165 ms today #6185

The milestones plan now names its stretches in Server-Timing, but I made no speed change. Locally the plan already builds in well under 50 ms, so I couldn't reproduce the 165 ms and don't know what slows it on trevato/forge. Only the new test and the milestones tests were run (18 pass, tsc clean). I didn't run design-lint, because nothing under src/web/ is markup.

• What changed: readPlan (src/core/milestones.ts) takes an optional stretch(name, ms) callback. It reports graph (pillars, repo graph, limb tree and seats), crew (open pulls and active runs), week (merged pulls), spend (cost and ever-merged, owner view only) and limbs. planFor (src/web/pages/milestones.ts) passes it to notePhase, so a cache miss shows plan-graph, plan-crew, plan-week, plan-spend and plan-limbs next to plan.
• Names: they use hyphens, not the dots the issue suggested, because phase names can't contain a dot.
• Slowest stretch: the plan is already kept until the repository's issues, edges, pulls, runs or seats change (#3643, #6122, #6152), and it reuses the repo graph built for the request. When it isn't kept, it reads in one pass over that single graph, with no per-issue queries. That is a fact about the code as it stands, not something this change added.
• Test: test/milestones-speed.test.ts builds 2,000 closed and 300 open issues across 10 limbs. A cold readPlan must fit 50 ms. It must report the five stretches in order. Each limb must show total 230, done 200 and open 30. A cold page request must carry plan-graph and plan-limbs.
• Sealed issues: the graph and limb counting are untouched, so a sealed issue stays out of a limb for a viewer who can't see it.
• Next step: once this is deployed, the plan-* numbers on trevato/forge's cold request will show which stretch is the slow one.

Closes #6182

The milestones plan now names its stretches in Server-Timing, but I made no speed change. Locally the plan already builds in well under 50 ms, so I couldn't reproduce the 165 ms and don't know what slows it on trevato/forge. Only the new test and the milestones tests were run (18 pass, tsc clean). I didn't run design-lint, because nothing under src/web/ is markup.

• What changed: readPlan (src/core/milestones.ts) takes an optional stretch(name, ms) callback. It reports graph (pillars, repo graph, limb tree and seats), crew (open pulls and active runs), week (merged pulls), spend (cost and ever-merged, owner view only) and limbs. planFor (src/web/pages/milestones.ts) passes it to notePhase, so a cache miss shows plan-graph, plan-crew, plan-week, plan-spend and plan-limbs next to plan.
• Names: they use hyphens, not the dots the issue suggested, because phase names can't contain a dot.
• Slowest stretch: the plan is already kept until the repository's issues, edges, pulls, runs or seats change (#3643, #6122, #6152), and it reuses the repo graph built for the request. When it isn't kept, it reads in one pass over that single graph, with no per-issue queries. That is a fact about the code as it stands, not something this change added.
• Test: test/milestones-speed.test.ts builds 2,000 closed and 300 open issues across 10 limbs. A cold readPlan must fit 50 ms. It must report the five stretches in order. Each limb must show total 230, done 200 and open 30. A cold page request must carry plan-graph and plan-limbs.
• Sealed issues: the graph and limb counting are untouched, so a sealed issue stays out of a limb for a viewer who can't see it.
• Next step: once this is deployed, the plan-* numbers on trevato/forge's cold request will show which stretch is the slow one.

The milestones plan now builds in about 40 ms on a trevato/forge-shaped repository, where the code on main takes about 77–90 ms. A kept plan now costs about 0.1 ms to confirm instead of about 14 ms. I couldn't measure the real 165 ms, because the lab app has no trevato/forge repository to measure. The new fixture is my guess at its shape, so check the plan-* numbers on a real cold request.

The map, milestones, dependencies and new speed tests pass, and tsc is clean. The new tests were run in the sandbox against both main's code and this branch. I didn't run design-lint, since nothing under src/web/ is markup.

Where the time went. The new fixture in test/milestones-shape.test.ts has 2,000 closed and 300 open issues across 10 nested limbs, 400 of the 3,000 pulls merged this week, 1,500 runs, and sealed issues. It reproduces a plan of roughly 80–110 ms on main.

• Stamp read: the stamp read ran five aggregate queries on every request, even when the plan was already kept, about 14 ms each time. planStamp now reuses its last stamp while core/write_clock.ts says nothing was written. That clock is forge-wide, so any write anywhere forces a re-read, but it is never stale.
• Graph read: this was the largest stretch of a cold build. It loaded every issue row of the repository, pull bodies included, though dependencies only join issues. getIssuesOfRepo now takes a kind and a lean flag. The plan reads only issues, without bodies, because no plan consumer reads a body. repoGraph takes lean; readPlan passes it.
• Spend read and merged-pull list: the spend query no longer loads the body of every costed issue, only of pulls. The list of every merged pull's closes is now read only when one milestone's page asks for it. The list of limbs never shows it.
• Reused graph: the plan is built from one repo graph per request, and the cache still keeps it by stamp.

Tests. They fail on main's code and pass here.

• Speed: the cold build must stay under 50 ms, taking the best of 7 runs, with the shared load-relaxed budget helper.
• Limbs unchanged: each limb's total, done, open, merged, building and spend are compared with figures captured from main's code, with and without spend.
• Sealed issues: none appears in the plan graph.
• Stamp: repeat reads stay cheap, and the stamp moves when an issue opens.

Feedback points.

• stretch is not a second timing path. It only calls notePhase from route_timing.ts, because core/ can't see the request. The plan-* names use hyphens because phase names can't contain a dot.
• The README now says the plan-* stretches appear only on the request that built the plan, and that on a kept plan plan is just the stamp read.

Not done.

• A cold plan is still about 40 ms, so the real page may still exceed 50 ms on a cold request on a loaded machine.
• I tried an i.kind = 'issue' filter on the edge query and a new migration with indexes. The filter reordered edges and broke map.test.ts, so I reverted it. The indexes gained nothing, so I dropped them.
• A repo with few edges still reads issue bodies through the small-graph path. That is harmless, since nothing reads them.

Closing the issue. The Done when list is met by the stretch names, the fixture test and the unchanged counts. Whether it closes the issue is your call, given I couldn't measure the real 165 ms.