Deploy peer-wait: progress-based (no-progress) timeout for awaitDeploymentRow

Follow-up to #402 (fixed by harper#1338, the Option-1 pragmatic fix: configurable `deployment_timeout` + 120s default + clearer error).

#402 suggestion #2 — replace the fixed wall-clock peer-wait with a **progress-based / no-progress timeout** — was deferred. Instead of failing a peer after a fixed budget regardless of whether replication is advancing, `awaitDeploymentRow` (in core `components/deploymentRecorder.ts`) could keep waiting as long as the `system`-table replication is observably making progress, and fail fast only when it is genuinely stalled. That waits indefinitely under slow-but-alive replication and fails quickly on a dead channel — strictly better than any fixed number.

**Why it wasn't done in harper#1338:** the obvious progress signal (the row appearing at all, even with `payload_blob = null`) is unreliable, because the origin's `create()` and `ingestPayload()` writes happen back-to-back, so a peer rarely observes the intermediate "row present, blob null" state. A robust implementation would need a real replication-progress signal (e.g. the system table's applied position advancing), which is more involved. Filing to track if the 120s default + override still proves insufficient on heavily-backlogged clusters.

_Code lives in harper core; this issue tracks it from the harper-pro side alongside #402._