id(world): world logs --seconds and world mirror --timeout-secs panic on huge values — unchecked u64 seconds added to an Instant #2396

Summary

Two id world CLI commands turn an unchecked u64 seconds argument into a deadline by adding it to an Instant, and a huge value panics the process with overflow when adding duration to instant instead of being refused or clamped:

1. id world logs --seconds <huge> — pkgs/id/src/commands/world.rs:563-564:

   let deadline =
       tokio::time::Instant::now() + std::time::Duration::from_secs(seconds.max(1));

   seconds is a plain clap u64 (pkgs/id/src/cli.rs:1820-1828, --seconds, default 5, no range). The deadline is computed after connect + join, so the command connects successfully and then crashes with a panic.
2. id world mirror --timeout-secs <huge> — pkgs/id/src/commands/world.rs:152 builds Duration::from_secs(timeout_secs.max(1)) (--timeout-secs, plain u64, pkgs/id/src/cli.rs:1490-1491) and passes it to crate::world_records::replicate, which at pkgs/id/src/world_records.rs:218 computes:

   let deadline = std::time::Instant::now() + timeout;

   The earlier tokio::time::timeout(timeout, …) at world_records.rs:205 survives huge durations (tokio caps its internal deadline — verified), so the panic lands on the std Instant addition at :218, after the initial sync has already run.

Evidence (verified this run, main 5a34fa70)

Laptop probe crate ~/git/fleet/probe-2026-10-29-logsinstant/ (verbatim deadline expressions):

• std::time::Instant::now() + Duration::from_secs(u64::MAX) → panics overflow when adding duration to instant, exit 101.
• tokio::time::Instant::now() + Duration::from_secs(u64::MAX) → same panic, tokio 1.54.1 at tokio/src/time/instant.rs:161 (id's Cargo.lock pins tokio 1.53.2, same documented panic-on-overflow semantics).
• Control: Duration::from_secs(86400) deadline computes normally, exit 0.
• tokio::time::timeout(Duration::from_secs(u64::MAX), …) does not panic (completes normally) — confirming Mirror's crash site is the std addition at world_records.rs:218, not the timeout at :205.

Other Instant::now() + … sites in the crate use constants or internal durations (world_compile.rs:296 uses the COMPILE_TIMEOUT constant; event_store/sync.rs:314, store.rs:124 fixed values) and are not user-reachable with arbitrary values — only these two CLI paths are.

Why it matters

A typo'd or script-generated --seconds 99999999999999999999-class value crashes the CLI with a Rust panic (exit 101, backtrace hint) instead of a clean "value too large" error, in one case after a successful connect/join and in the other after the initial sync. It is the same unchecked-seconds shape the fleet has been filing in mcpx (#2231/#2351/#2368), here in the id CLI's own argument surface.

Acceptance criteria

• id world logs --seconds 18446744073709551615 no longer panics: it is either refused at parse time with a message naming --seconds, or clamped to a documented maximum deadline.
• id world mirror --timeout-secs 18446744073709551615 no longer panics at world_records.rs:218 (same rule: refuse or clamp, naming --timeout-secs).
• The chosen rule is applied consistently at both sites (one shared helper or identical clap value_parser range), and the maximum is documented in the --help text or the error message.
• Regression tests: a unit test for the clamp/refusal at the boundary value, and existing world logs / world mirror argument-parsing tests still pass.
• Normal values are unchanged: --seconds 5 (default) and --timeout-secs 30 (default) behave exactly as before.

Dedup

Searched open + closed issues for "world logs", "logs seconds", "Instant overflow": no covering issue. #2125 (peers --depth=-1) is a different argument/mechanism; #2231/#2351/#2368 are mcpx (TypeScript) duration ceilings in other code paths.