Deferred follow-up to #79, which made F-001 a CPU-time budget only and left the wall-clock TimeoutGuard dormant. This re-wires the wall-clock guard as an independent, opt-in limit that complements the CPU budget.

What changed

• New env knob AGENT_OS_V8_WALL_CLOCK_LIMIT_MS. When set (>0) it arms the wall-clock TimeoutGuard in the session execution path, alongside the CpuBudgetGuard. Threaded through the CreateSession/Start frame next to the existing CPU-budget knob (AGENT_OS_V8_CPU_TIME_LIMIT_MS).
• Off by default. Unset / 0 normalizes to None, so the guard is not armed and there is no wall-clock limit. Long-lived ACP adapters run indefinitely on wall-clock and are not killed by a default. The CPU budget remains the primary guard.
• Coexists with the CPU budget. Both guards can be armed at once; whichever fires first calls terminate_execution. The recorded ExecutionAbortReason is authoritative (first-writer-wins), and the result frame attributes termination to the correct guard:
  • wall-clock: ERR_SCRIPT_WALL_CLOCK_EXCEEDED
  • CPU budget: ERR_SCRIPT_CPU_BUDGET_EXCEEDED
• Independent semantics. Unlike the CPU budget (which counts active JS CPU only, excluding idle/await), the wall-clock backstop counts elapsed real time including idle/await — so it can cap a guest that blocks or awaits indefinitely.

Tests (bounded; fenced behind worker-thread + recv-timeout)

Added to the V8 integration suite:

1. Wall-clock SET small -> an awaiting guest (~1.5s await, 300ms limit, no CPU budget) is terminated with the wall-clock reason — proving idle/await is counted.
2. CPU budget only -> no wall-clock limit imposed; an awaiting guest completes cleanly (knobs independent).
3. Neither set -> no time limit of any kind (strictly opt-in).

Verification

• cargo fmt --all --check clean
• cargo build --workspace green
• New + existing V8 integration suite and v8-runtime tests pass