A pull's resolve page's Server-Timing names its phases: session, each read, render #3501

The resolve page (GET /:owner/:name/pulls/:number/resolve) now answers with a Server-Timing header that names where its time goes. The new test and the other conflict tests pass (15 tests). I couldn't run bun x tsc --noEmit: bun can't write its tempdir here, so bun install failed too. The forge's check will be the first type check.

What changed

• conflictsPage in src/web/pages/conflicts.ts names these phases after app, in this order: session, pull, checkout, status, file, crew, render. It uses notePhase/timePhase/timePhaseAsync, the same way the milestones page does.
• The phases are the pull and repo lookup, the pull's checkout (pullDir), pullStatus, readConflictedFile, and the crew proposal card.
• Each read keeps its order and its errors, and the body, status codes and caching are unchanged.
• One thing moved: the crew card is now built before the page body instead of inside it, so it can have its own phase. It's an independent read, so the output is the same.
• The "nothing to resolve" path also names session, pull, checkout, status, crew and render. It skips file because it never reads one.
• test/conflicts-timing.test.ts builds a pull whose branches conflict, requests the page, and asserts the phase names, their order, and that each has a dur= value. It asserts no wall-clock time, and it fails on the base code.

Left out

• No other page was touched.
• The "nothing to resolve" path has no test of its own.

To try it: open a conflicted pull's /resolve page and read the Server-Timing response header.

🤖 Generated with Claude Code

Closes #3463

The resolve page (GET /:owner/:name/pulls/:number/resolve) now answers with a Server-Timing header that names where its time goes. The new test and the other conflict tests pass (15 tests). I couldn't run bun x tsc --noEmit: bun can't write its tempdir here, so bun install failed too. The forge's check will be the first type check.

What changed

• conflictsPage in src/web/pages/conflicts.ts names these phases after app, in this order: session, pull, checkout, status, file, crew, render. It uses notePhase/timePhase/timePhaseAsync, the same way the milestones page does.
• The phases are the pull and repo lookup, the pull's checkout (pullDir), pullStatus, readConflictedFile, and the crew proposal card.
• Each read keeps its order and its errors, and the body, status codes and caching are unchanged.
• One thing moved: the crew card is now built before the page body instead of inside it, so it can have its own phase. It's an independent read, so the output is the same.
• The "nothing to resolve" path also names session, pull, checkout, status, crew and render. It skips file because it never reads one.
• test/conflicts-timing.test.ts builds a pull whose branches conflict, requests the page, and asserts the phase names, their order, and that each has a dur= value. It asserts no wall-clock time, and it fails on the base code.

Left out

• No other page was touched.
• The "nothing to resolve" path has no test of its own.

To try it: open a conflicted pull's /resolve page and read the Server-Timing response header.

🤖 Generated with Claude Code