fix(deploy): make peer deployment-row wait configurable, default 120s

[kriszyp]

Summary

Fixes the peer-side timeout in replicated deploy_component reported in harper-pro#402. Since 5.1.x the deployment-tracking feature moved the payload off the operation body into the system.hdb_deployment row's payload_blob; peers wait for that row to replicate via awaitDeploymentRow, which hardcoded a 30s deadline with no way to extend it. Under system-table replication backlog the row arrives later than 30s, so the peer threw Timed out … waiting for hdb_deployment row … and the deploy failed.

• Default peer-wait 30s → 120s (DEFAULT_AWAIT_ROW_TIMEOUT_MS).
• New optional deployment_timeout deploy operation parameter (ms) to extend the budget per-deploy on heavily-backlogged clusters; added to the Joi schema.
• Poll loop now runs at least once (so deployment_timeout: 0 performs a single lookup rather than no-op'ing) and caps the final sleep to the remaining budget.
• Timeout error now distinguishes "row never replicated" (dead/stalled channel) from "row arrived but payload_blob pending" (origin's ingestPayload write still in flight).

Where to look / what to weigh

• deploymentRecorder.ts — the 120s default. Rationale: a deploy is rare and heavyweight, and the issue's evidence (the initial deploy always succeeds because the row beats 30s; rows arrive mid-wait) shows the row replicates on a path independent of the waiting op — so the longer wait extends patience without deadlock risk. A peer that will ultimately fail now takes up to 120s (or the operator's deployment_timeout) to report it, instead of 30s. Worth a sanity check that 120s is the right default vs. something larger/smaller.
• deployment_timeout propagation. The param is set on the origin call and carried to peers via the replicated operation body (the origin only deletes payload/progress before replicating), which is what lets peers honor it. Confirm that's the intended delivery mechanism.
• Defensive Number() coercion of timeoutMs. validateBySchema discards Joi's coerced value, so a numeric-string deployment_timeout from a JSON/multipart client would otherwise reach the arithmetic as a string and concatenate into a far-future deadline. Coerced + finite/non-negative guarded in the helper (the single chokepoint where the timestamp math lives).

Follow-up (not in this PR)

This is the pragmatic Option-1 fix from the issue. The progress-based / no-progress timeout (issue suggestion #2) is deferred — I'll file a follow-up to track it; the create()→ingestPayload() writes happen back-to-back on the origin, so the intermediate "row present, null blob" progress signal is unreliable in practice and the marginal benefit is uncertain.

Tests

Unit coverage added for the configurable timeout, the numeric-string/NaN coercion, the timeoutMs: 0 single-poll behavior, the two distinct timeout messages, and validator accept/reject of deployment_timeout.

---

🤖 Generated by Claude (Opus 4.8, 1M context). Reviewed cross-model (Codex + Gemini) before opening; the findings they surfaced are already addressed in the diff.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[claude]

Reviewed; no blockers found.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!