The clock bridge gets a reader, and states what its bound is worth

[Quchaosheng]

Closes nothing on its own — this is the work #220 asks for, and the check it asks to have made first.

What was missing

robot.state, tof.frame and head_imu.frame carry t_ns (CLOCK_MONOTONIC), and media.video publishes the mono_ns/real_ns pair read together — that is the boot epoch the issue asks for, and it landed at v24. What did not exist was anything on the receiving side: the pair had no reader anywhere in the repo.

What this does

• proto::clock::ClockPair — the bridge as a type. media.video's params now read their pair through ClockPair::now() rather than as two bare adjacent calls, which puts "these two readings belong together" in the type instead of in a comment and leaves no way for the next caller to read them a second apart. ClockPair::wall() is the receiving end: the addition that turns a t_ns into a wall-clock moment. It has no caller in this workspace, and the doc comment says so — the receivers that need it are the ones §11 describes, a peer that reads RTP rather than a robot daemon.
• A clock row in the console — telemetry now shows a robot.state sample's wall-clock moment and its age.
• §11 rewritten. It said wanted / not built, which stopped being true at v24 and was never corrected. AGENTS.md says the doc is the bug when it disagrees with behaviour.

The check §11 asked for first, and what it found

abs-capture-time is a dead end: webrtcsink configures TWCC and color-space and nothing else (0.15.3 and main), aiortc does not parse it, and neither the WebRTC specification nor the stats one has a capture-time member.

So frames are dated from RTCP sender reports, whose NTP time is the realtime clock by default (rtpmanager's ntp-time-source is ntp). The part the check turned up that the section did not expect: this only works for one kind of receiver. Dating a frame needs the report's RTP time as well as its NTP time, and only GStreamer exposes both (sr-rtptime beside sr-ntptime in rtpsession's stats). aiortc and every browser see the NTP half alone, so they can say what the sender's clock read and not which frame it was.

The bound

The issue asks for something written down rather than inherited from the network. The kernel's own ceiling on NTP's frequency discipline is MAXFREQ, 500 ppm of the pair's age — 30 µs over a minute, 1.8 ms over an hour.

That covers slewing, not a step, and the step is not hypothetical here: this board has no battery-backed RTC, boots at 1970, and NTP steps the clock (scripts/provision.sh says so, and pad-link-test.sh refuses the wall clock for the same reason). A pair taken before that first step is wrong by decades while looking like an ordinary number. Whether the clock has been set is updater's judgement — updater/src/preflight.rs owns that floor — so this points there rather than adding a second threshold to keep in step.

Verification

cargo test -p duck-ipc-proto — 53 passed. cargo fmt --check clean, clippy -D warnings clean. Additive throughout, so no API_VERSION bump.

One caveat: cargo test -p mediad needs the GStreamer C libraries, which the machine this was written on could not install, so the session.rs and console changes have not been through mediad's tests. The session.rs change is mechanical (two calls → one struct field) and ClockPair itself is covered.

Assisted-by: DeepSeek v4.1 via DSH