Validate navigate URLs and exec timeouts on the Bot computer

[Ayush7614]

What

Two shape checks on the Bot computer itself (agent-computer), which holds no policy engine — so a malformed call should be a 400 naming the field, not a 502 that reads as a broken computer:

• POST /navigate accepted any string into page.goto: an empty string came back 502 Navigation failed, and javascript:/file:///data:/ftp: URLs were never refused up front. New parseNavigateUrl trims, requires a parseable URL, and allows only http:/https:.
• POST /exec forwarded NaN/Infinity into the shell, where Math.max(NaN, 1000) stays NaN and setTimeout(NaN) fires at once — the command reported timed out before doing anything. New parseExecTimeout enforces whole milliseconds in 1000..600000 (matching the server gateway), and shell.run falls back to its default on a non-finite value so a direct caller gets a run rather than a lie.

Why it matters

The computer is the Bot's SSRF surface (/navigate) and its most expensive action (/exec). Both previously failed in ways that pointed at the computer instead of the caller. The shared validation module (agent-computer/src/request-validation.ts) is pure and unit-tested without a browser.

Verification

• agent-computer/tests/request-validation.test.ts (new): 11 invalid navigate inputs rejected, 10 invalid timeouts rejected, valid inputs pass — 24 pass.
• agent-computer/tests/shell.test.ts (+2 NaN/Infinity cases): a non-finite timeout now runs the command with the default instead of reporting an instant timeout — 23 pass.
• bun run --filter server typecheck — clean (agent-computer's pre-existing missing playwright/spiffe deps in this env are untouched). Biome format + lint — clean.

[davidmckayv]

navigate-URL + exec-timeout validation. Deep-reviewed clean (no SSRF/over-block). CI failure was pre-existing handoff-integration flakiness (baselined 3/5 on clean main); rerun green.