fix: keep build log reads independent of deploy status polling

[Fermionic-Lyu]

Slow build-log requests could consume the CLI's 3-second live-read budget, repeatedly interrupt pagination, and delay deployment status polling. Terminal polling also shared its time budget with the final full scan, so normal API latency could skip that scan and miss delayed output.

Run archive deployment status polling and log reading independently. Status polling retains its 3-second interval; log reading emits and checkpoints each page, waits 3 seconds between completed reads, and gives each HTTP request a 20-second timeout. Cancel and drain the background reader before terminal scans and on every deployment exit. Final scans retain an independent budget of up to 30 seconds, capped by the remaining deployment deadline. HTTP failures and real timeouts remain visible; intentional shutdown does not produce a false failure warning.

Validation:

• Typecheck and all 1,625 tests across 80 files pass.
• Regression coverage includes 4-second pages and a 36-second live scan, status polling during slow reads, 20-second page timeout/resume, cancellation on terminal/error/deadline exits, and bounded final scans with delayed output.
• Read-only production verification retrieved all 60 LIVE, 100 PAGE, and FINAL markers from a retained build with no warnings, including 150 ms of injected client latency. No production configuration or resources changed.

This change is confined to CLI log retrieval and presentation; service-side build scheduling and deployment orchestration are unchanged.

[agent-zhang-beihai]

Reviewed by Yang Dong

This separates the short archive-log polling window from the deployment deadline and performs a bounded final full scan without duplicating output. The timeout and cursor handling remain within the caller’s deadline, and I found no findings; APPROVE.

[agent-zhang-beihai]

Reviewed by Wang Miao

All 1619 tests and the typecheck pass on the head, and the six new archive-watcher tests fail on the base commit — so they pin the behaviour this change adds rather than restating what already worked.

I traced the two-deadline split (refreshDeadline for the 18s/3s polling window, deadline for the caller's remaining deploy budget) through every attempt path: fast reads still finish at attempt 5, a read that eats the whole refresh window falls through to a single 30s final read with tails cleared, and both are still capped by deadline - now so the watcher can never outlive the deploy deadline that deployArchive hands it. The silent continue on an aborted non-final read is reachable only where a later attempt (or, in the live case, the next poll) covers the same ground, and a persistent failure still surfaces on the terminal read.

No findings.

[jwfing]

LGTM - approved.

[cubic-dev-ai]

All reported issues were addressed across 2 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 4 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[jwfing]

LGTM - approved.