fix(app): give worktree creation a setup-length request deadline

[Hona]

Since #47572 every request is aborted if the server has not sent response headers within 60 s. POST /api/worktree cannot meet that: the server runs git worktree add and then the project's commands.start script (fetches, bun install) before it answers. On this repo that is 90–120 s on Windows.

sequenceDiagram
  participant App
  participant Server
  App->>Server: POST /api/worktree
  Server->>Server: git worktree add (5–18 s)
  Server->>Server: commands.start: fetch + switch + bun install (70–90 s)
  Note over App: 60 s deadline fires
  App--xServer: abort → 499
  Note over Server: fiber interrupted, bun install killed,<br/>worktree already registered in DB

Loading

• POST /api/worktree now gets its own setupRequestHeadersTimeoutMs (10 min). Still bounded, so the dead-socket protection from fix(app): time out requests the server never answers #47572 remains.
• GET /api/worktree, /api/worktree/refresh, DELETE, and /api/vcs keep the 60 s deadline.
• The slow-slot cap (2) already limits how many long requests can hold slots at once.

export const setupRequestHeadersTimeoutMs = 10 * 60_000

export function isSetupRequest(method: string, pathname: string) {
  return method === "POST" && pathname === "/api/worktree"
}

const timer = setTimeout(
  () => controller.abort(new DOMException("Timed out waiting for the server to respond", "TimeoutError")),
  isSetupRequest(request.method, pathname) ? setupHeadersTimeoutMs : headersTimeoutMs,
)

Follow-up worth doing separately: have the server return after git worktree add and run commands.start in a forked fiber with progress on worktree.updated, so the client never has to hold a multi-minute request.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.