[Fix] Previews time out immediately after environment setup

[roomote-roomote]

​Opened on behalf of @mrubens. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

• waits for configured preview routes after successful detached environment commands instead of treating PM2 process survival as application readiness
• warms each preview's configured initial path across IPv4 or IPv6 loopback and accepts redirects and other non-server-error responses as ready
• preserves the loopback authority even when an initial path begins with //, preventing readiness probes from targeting another host
• uses the longest successful detached command's configured timeout for readiness, capped at the 60-minute task lifecycle limit
• reports the latest probe result every minute while waiting and includes it with the detached-command log location in terminal warnings
• adds focused coverage for initial-path warming, retries, long startup, timeout capping, diagnostics, IPv6 routing, and setup-status warning propagation
• runs database integration test files sequentially because they intentionally share one database and perform fixture cleanup that can otherwise race across files

Why this change was made

Detached setup commands were marked complete after a two-second process-survival check even when their HTTP servers were still compiling or had not bound their ports. That allowed preview requests to arrive during startup and fail or time out.

The database test suite also ran integration files concurrently against one shared database; file-level fixture cleanup could delete rows another test still needed, producing nondeterministic CI failures.

Impact

Environment setup now settles cleanly only after configured previews accept HTTP requests, without allowing configured paths to redirect the probe off loopback. The default readiness budget is 10 minutes rather than one minute, explicit command timeouts are honored up to the one-hour task limit, and each HTTP attempt remains capped at five seconds. Genuinely failed previews produce periodic diagnostics and a terminal warning instead of hanging setup indefinitely. Database tests take longer but no longer corrupt each other's shared fixtures during parallel file execution.

[roomote-community]

No new code issues found. See task

• Prevent initial_path from replacing the loopback host during readiness checks.

_{Reviewed d838e91}

[roomote-roomote]

Updated the readiness policy in d838e91. Readiness now uses the longest successfully launched detached command’s configured timeout (10 minutes by default), capped at the one-hour task limit; ports are checked concurrently, each HTTP attempt is canceled after at most five seconds, failures retry after one second, and the latest probe diagnostic is logged every minute and included in the terminal warning with the setup-log location. A preview that becomes ready after 90 seconds is covered explicitly. Focused tests (9), the full worker suite (1,845), static checks, pre-push checks, and the refreshed GitHub CI run all pass. No additional visual proof was attempted after the earlier proof-capture timeout; these are non-visual worker lifecycle changes.