Composite request envelopes: batch and replay must cover their steps' worst case or hold a daemon deadline #3325

Follow-up 2a from #2879 (step 1 landed in #2916).

Problem

batch and replay run many steps inside one client request envelope, and neither holds a daemon-side deadline. When the envelope fires, onTimeout: 'reset-daemon' kills the daemon and every session it owns.

• batch: timeoutPolicy: DEFAULT_TIMEOUT_POLICY (90 s for the whole request, packages/command-registry/src/registry.ts, name: 'batch').
• replay: { ...DEFAULT_TIMEOUT_POLICY, budget: { source: 'flag' } }. With no --timeout the envelope is 90 s. With --timeout X it is exactly X, and no daemon code reads that budget, so the margin is zero.

One fold step has a proven worst case of about 225 s (FOLD_REQUEST_TIMEOUT_MS = 255_000, ledger in test/integration/provider-scenarios/ios-fold.test.ts). longpress (210 s) and install (180 s) are also batchable or recorded. A batch or .ad replay that contains any of them can overrun the envelope and reset the daemon instead of returning a typed result.

Decision needed

Choose one:

• Derived envelope. The client sums the resolved envelopes of the steps it sends (batch --steps / --steps-file). replay would need the client to parse the script first.
• Daemon deadline. batch and replay hold a daemon-side deadline that ends at least 30 s before the envelope and returns a typed timeout, following the lease_allocate shape (LEASE_ALLOCATION_BUDGET_MS). replay --timeout is documented as the request's wall-clock maximum (src/commands/replay/index.ts), so its envelope becomes X + 30 s (margin budget mode) instead of X.

Done when

A provider-scenario test runs batch with one worst-case fold step (the #2879 ledger fake) and replay of a one-line .ad fold script, with and without --timeout. Every run ends in the daemon's typed result, never in a client timeout and daemon reset. test stays unbounded and out of scope.