Request clock: wall-time consumers outside ClientManager, and suites that hang on a broken idle timeout (follow-up to C3 of #235) #293

Two items the review board on #292 (slice C3 of #235) raised and deferred as out of scope. Both predate C3.

1. Consumers outside ClientManager assume the request clock is wall time

ClientManager now takes an injected request clock (clock=, default time.time). Two consumers outside it subtract time.time() from values that clock stamped:

• gateway.list_pending in src/pmcp/tools/handlers.py (~6324–6341): elapsed_seconds, last_heartbeat_seconds_ago, and datetime.fromtimestamp(started_at);
• pmcp status in src/pmcp/cli.py (~1478, ~1549).

They're correct only because the default clock is wall time. That's intended: plan decision 3 says so, and test_default_request_clock_is_wall_time pins it. But any future non-wall clock, including the planned move to time.monotonic() for NTP-step immunity, would make those numbers meaningless.

To fix: have ClientManager expose ages (now - stamp on its own clock) rather than raw stamps, or convert the stamps at the boundary. Then switch the request clock to monotonic.

2. Other suites hang when the idle timeout is broken

With the idle path disabled (mutant M12: now = pending.started_at in _await_with_idle_timeout), the C3 TestIdleTimeout tests fail by name in about 5 s each. But a run over mcp2x/test_client_transport, runtime/test_downstream_remote, test_phase4_e2e, test_phase6_tenant_code_mode and test_tools produced no pytest summary within 300 s, because real-request tests there wait out pytest-timeout (700 s). A real regression in the idle path would therefore show up in CI as a cancelled job rather than a red test (compare #200).

To fix: give those real-request tests a request-level deadline, or a small PMCP_REQUEST_CEILING_MS, so a broken timeout fails by name.

Source: board findings N4 (claude; also grok F004 and gemini F-02) and N5 (claude) on #292.