A repository's following page's Server-Timing names its phases: session, each read, render #3502

The following page (GET /:owner/:name/following) now answers with a Server-Timing header that names its phases. The type check is clean and the new test passes. It fails on the original chain.ts, as it should, and the existing spawn-chain* suites still pass. I did not run the whole bun test; the forge runs the whole check on this push.

• Phases: the header carries session, repo (loading the repository), chain (the check that this repository carries the chain, plus the chain read), parent (reading the parent credential), proposals, upstream and render. proposals appears only when the page actually reads proposals. The timing calls use notePhase, timePhase and timePhaseAsync from src/core/route_timing.ts, the way milestones.ts does.
• Unchanged: the body, the status codes, the caching, and the order and error behaviour of every read. The only code that runs for the header is the timing calls.
• Test: test/chain-timing.test.ts boots a spawned forge, requests /kid/forge/following as the owner, and asserts each phase name appears with a duration. It asserts names only, never a wall-clock time.
• Left out: the POST handlers (sever, check, take, mode, propose) and every other page, as the issue asks. A repository that doesn't carry the chain still redirects to its home, now with session, repo and chain timed.
• To try it: bun test test/chain-timing.test.ts, or curl -sI the following page of a forge that follows a parent and read server-timing.

Closes #3461

The following page (GET /:owner/:name/following) now answers with a Server-Timing header that names its phases. The type check is clean and the new test passes. It fails on the original chain.ts, as it should, and the existing spawn-chain* suites still pass. I did not run the whole bun test; the forge runs the whole check on this push.

• Phases: the header carries session, repo (loading the repository), chain (the check that this repository carries the chain, plus the chain read), parent (reading the parent credential), proposals, upstream and render. proposals appears only when the page actually reads proposals. The timing calls use notePhase, timePhase and timePhaseAsync from src/core/route_timing.ts, the way milestones.ts does.
• Unchanged: the body, the status codes, the caching, and the order and error behaviour of every read. The only code that runs for the header is the timing calls.
• Test: test/chain-timing.test.ts boots a spawned forge, requests /kid/forge/following as the owner, and asserts each phase name appears with a duration. It asserts names only, never a wall-clock time.
• Left out: the POST handlers (sever, check, take, mode, propose) and every other page, as the issue asks. A repository that doesn't carry the chain still redirects to its home, now with session, repo and chain timed.
• To try it: bun test test/chain-timing.test.ts, or curl -sI the following page of a forge that follows a parent and read server-timing.