Populate observation capture timestamps

[Nzouh]

Summary

• record one monotonic capture timestamp after each combined SO-ARM observation read
• populate Observation.image_times for every configured camera
• populate Observation.state_time
• add deterministic coverage using the injected clock

The driver exposes one combined observation read, so the state and configured cameras share that capture timestamp rather than reporting false per-sensor precision.

Closes #3.

Validation

• python -m pytest --cov (82 passed, 100% coverage)
• python -m ruff check .
• python -m ruff format --check .
• python -m mypy src/inspect_robots_so101/embodiment.py

[Copilot]

Pull request overview

This PR ensures each SO-ARM observation includes deterministic “capture time” metadata by recording a single monotonic timestamp immediately after the driver’s combined observation read, and propagating it into Observation.image_times (per configured camera) and Observation.state_time. This aligns timestamps across state + images (since they’re acquired together) and makes the behavior testable via an injected clock.

Changes:

• Record one monotonic timestamp after each get_observation() call and store it in the returned Observation.
• Populate Observation.image_times for all configured cameras and Observation.state_time.
• Add a unit test that verifies deterministic timestamps using an injected clock.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
tests/test_embodiment.py	Adds coverage asserting image_times/state_time are populated from the injected clock.
src/inspect_robots_so101/embodiment.py	Captures a monotonic timestamp after the combined observation read and fills image_times/state_time.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jeqcho]

Nice fix for #3. Stamping one shared time instead of faking per-sensor precision is the right call given the driver exposes a single combined get_observation() read, and reusing the injected clock seam keeps the suite deterministic.

I ran the gates locally (pytest with 100% coverage, ruff, mypy, all clean) and verified this merges cleanly with your #19.

One optional ask: add a one-line comment noting the timestamp is monotonic (perf_counter timebase, in-process only, not wall time). The framework doesn't document a timebase for image_times/state_time yet, so future consumers will otherwise have to guess. Happy to merge either way.

[jeqcho]

Merged, thank you. Good judgment on the single shared timestamp given the driver's combined read, and the iterator-clock test made this easy to verify. Ships in the next release.