Stop processing deferred entries after recovery deadline

Once now >= deadline, this loop performs a failDelivery read/write/rename for every remaining queue item before returning, which can take arbitrarily long on large queues or slow disks and effectively nullifies the documented maxRecoveryMs wall-clock cap for startup recovery. The same unbounded work pattern is also present in the now + backoff >= deadline branch, so recovery can still block startup well past the configured budget.

Useful? React with 👍 / 👎.

Keep recovery warning text consistent with existing assertions

This changes the timeout warning from deferred to next restart to deferred to next startup, but recoverPendingDeliveries is still asserted against the old wording in src/infra/outbound/outbound.test.ts:448 (expect.stringContaining("deferred to next restart")). When maxRecoveryMs is exhausted, that test path now fails deterministically, so this commit will break the current recovery test suite unless the assertion or warning text is updated together.

Useful? React with 👍 / 👎.

Keep Chrome stderr piped during launch attempts

When Chrome fails to come up (for example because of a bad flag, missing display, or sandbox issue), launchOpenClawChrome still tries to read proc.stderr and append it to the thrown startup error, but this stdio setting makes proc.stderr null. That regresses a previously actionable failure path into an opaque Failed to start Chrome CDP... message with no browser diagnostics, which will make real startup issues much harder to debug.

Useful? React with 👍 / 👎.

Update deferred retries before breaking on recovery timeout

When maxRecoveryMs is exhausted, recoverPendingDeliveries() still only logs and breaks, so every queued item after the current cursor keeps its old retryCount. In the exact large-queue/slow-startup case this commit claims to fix, those same tail entries can be deferred on every restart and never reach MAX_RETRIES, because failDelivery() is the only path here that increments the counter and it is never called from the timeout branch.

Useful? React with 👍 / 👎.

Stop consuming retry budget for entries never retried

When recovery hits the startup time budget, this now runs failDelivery(...) on every untouched queue entry. failDelivery increments both retryCount and lastAttemptAt, so repeated restarts with a small maxRecoveryMs can exhaust MAX_RETRIES and move messages to failed/ without a single delivery attempt. I verified this by replaying recoverPendingDeliveries(..., maxRecoveryMs: 0) five times: the next normal startup archives the entry instead of calling deliver.

Useful? React with 👍 / 👎.

Move timed-out entries to failed once they hit MAX_RETRIES

When maxRecoveryMs is already exhausted (for example 0 or a consistently overloaded startup), this branch only calls failDelivery(...) on the remaining entries and then breaks before the later entry.retryCount >= MAX_RETRIES path can run. That means the exact scenario this fix is trying to stop can still loop forever: after 7 consecutive recoverPendingDeliveries(..., maxRecoveryMs: 0) runs, I still had the entry in pending/ with retryCount: 7 and nothing in failed/. The timeout path needs to archive maxed-out entries instead of blindly incrementing them again.

Useful? React with 👍 / 👎.

Check MAX_RETRIES before deferring timed-out entries

If recovery starts already past the deadline (for example maxRecoveryMs: 0 or a consistently too-small budget), this timeout branch runs before the entry.retryCount >= MAX_RETRIES check below, so queued files are only rewritten with ever-higher retryCount values and are never moved to failed/. I reproduced this by calling recoverPendingDeliveries(..., maxRecoveryMs: 0) seven times: the entry reached retryCount=7 and still remained queued, so the advertised “eventually pruned” behavior never happens under persistent budget exhaustion.

Useful? React with 👍 / 👎.