[test] Report deploy queue vs build timings in deploy tests

[eps1lon]

Adds queue-vs-build timing instrumentation to deploy tests, motivated by the -c 8 experiment in #99770 where deploy shard failures were all 240s hook timeouts and the queue-vs-build split had to be inferred from logs (remote builds took 21–31s while deployments took ~5min wall — the rest was Vercel-side queueing).

Per deployment, a [deploy-timing] line is logged, split from the deployment's lifecycle timestamps (createdAt / buildingAt / ready from GET /v13/deployments/:idOrUrl, using the same token and team scope the deploy itself used):

[deploy-timing] dpl_5tjX… state=READY upload=11.2s queued=271.3s build=24.1s cli-overhead=1.8s total=308.4s

Reported on all three paths:

• Success (deploy(), after the CLI returns)
• CLI/deploy failure (throwDeploymentError()) — distinguishes queue time from build time on failed builds
• Test aborted by hook timeout (destroy()): jest runs afterAll even when beforeAll times out, so destroy() now gives an in-flight deployment a bounded 90s grace to settle, then reports timings. If it still hasn't settled, a [deploy-timing] … timings unavailable line is logged instead.

To make the timeout path reachable, nextTestSetup's afterAll now always destroys the instance: previously await next?.destroy() silently skipped teardown when the beforeAll hook never resolved (jest timeout), leaving the running deployment to the module-level leak-detector afterAll (which then also failed the suite with "next instance not destroyed"). The afterAll now tracks the in-flight createNext promise, waits a bounded 30s grace, and falls back to the registered instance — so teardown runs, deployments settle enough to be timed, and the leak detector stays quiet. Both graces are sized to stay well under the 240s deploy hook timeout.

Safety: instrumentation can never fail a test — the API call is wrapped and only ever logs, and it no-ops when there is no token/scope (custom deploy script path) or no identifiable deployment.

Not included (deliberately): a shard-level post-step listing the run's deployments via the API — it would mix in unrelated deployments sharing the same Vercel project.

[github-actions]

Failing CI jobs

Commit: e72eba7 | About building and testing Next.js

[vercel]

Teardown grace Promise.race uses a ref'd timers/promises setTimeout, so the losing timer keeps the Jest worker's event loop alive for the full grace duration (90s / 30s) even after the deployment settles first.

[eps1lon]

Closing in favor of a simpler approach (get deployment ID synchronously at deploy start, time from there) to be done separately.