Fix HTTP startup after pre-ready worker restart

[kriszyp]

independent-review: claude + gemini + harper-domain; full review completed on dc5bf2c, one diagnostic-state race fixed afterward and revalidated with build, lint, and uWS integration coverage. Remaining review notes are called out below.

Summary

• Keep HTTP startup readiness with the logical worker slot, so a managed replacement can satisfy the original boot wait.
• Report each worker startup phase and turn bootstrap rejection into an explicit worker failure.
• Add an end-to-end uWS regression: crash the initial HTTP worker 0 once, then require the replacement to finish startup and run scheduler work.

Root cause and scope

The scheduled-run artifact proves stdout/stderr capture and process launch were working. The initial HTTP worker exited before its ready message; manageThreads launched a replacement, but startup was still awaiting the promise owned by the dead Worker object. The replacement created a different promise, so the original Promise.all() could never settle.

The exact trigger for that first worker exit was not retained in the old logs. This PR fixes the confirmed wait-ownership hang and makes a repeat observable by phase; it does not claim to identify the original worker failure.

The 60-second startup diagnostic is intentionally non-destructive. A hard boot cutoff or forced Worker.terminate() would create a new availability risk for slow deployments and Bun. A worker that wedges without exiting therefore remains an operational follow-up rather than changing production boot policy here.

Testing

• npm run build
• scoped oxlint --deny-warnings
• HARPER_UWS_HTTP=1 npm run test:integration -- integrationTests/server/initial-http-worker-restart.test.ts
• standard HTTP mode for the same integration test
• npx mocha unitTests/server/threads/threadServerListenOnPorts.test.js
• HARPER_UWS_HTTP=1 npm run test:integration -- integrationTests/components/scheduler-jobs.test.ts

The complete integration run was attempted earlier in this task; this regression passed, while unrelated Northwind concurrent CSV and local-Ollama tests failed in the environment.

[gemini-code-assist]

Code Review

This pull request improves HTTP worker startup resilience and diagnostics by tracking startup phases, implementing a startup timeout diagnostic, and handling exhausted restarts. It also adds integration tests to verify recovery when an initial HTTP worker crashes. The review feedback correctly points out that a worker's threadId is reset to -1 after exit in Node.js, and suggests capturing and tracking the active threadId synchronously during startup to ensure accurate logging when a worker exits or restarts are exhausted.

[claude]

Reviewed; no blockers found.