feat: add seconds-based task horizons

[Vedangalle]

Summary

Add seconds-based task horizons as an alternative to fixed step counts. This lets benchmark authors express a physical duration without coupling the task definition to one embodiment's control rate, while preserving the integer TaskEnvelope.max_steps contract used by adapters.

Changes

• Require each Task to declare exactly one of max_steps or keyword-only max_seconds.
• Validate seconds horizons and embodiment control_hz values as positive and finite.
• Resolve ceil(max_seconds * control_hz) after compatibility checking and before bind_task() or rollout, with a one-step minimum for positive floating-point underflow.
• Record the declared max_seconds and resolved max_steps in EvalLog schema v1 while preserving old-log compatibility.
• Show declared and resolved horizons in CLI notices, inspect, eval-set, and HTML reports.
• Document the design and migration behavior; update the changelog and edge-case coverage.

Rate-unknown and event-driven embodiments continue to use max_steps. Scorer interfaces, ad-hoc --max-steps, rollout pacing, and dependencies are unchanged.

Checklist

• pre-commit run --all-files and the pre-push hook stage pass.
• Tests added/updated, including mock-world orchestration and edge cases.
• Coverage remains at 100% line and branch (769 passed, 2 skipped).
• ruff check . and ruff format --check . pass.
• Strict mypy passes.
• CHANGELOG.md updated under "Unreleased".
• Public API behavior is documented and API snapshot tests pass; no new exported symbol is required.
• Core remains NumPy-only with no new dependencies.

Additional documentation checks:

• API reference generation passes.
• Docusaurus production build passes.

Related

Closes #160

[Adityakk9031]

please close this maintainer assigned this issue to me

[Adityakk9031]

check this robocurve/kitchenbench#29

[Vedangalle]

Thanks for flagging this, and sorry - I missed Jay’s note on KitchenBench #29 that #160 was yours first. I saw the framework issue unassigned and implemented it from there; I don’t want to duplicate or cut across your work.

Since #161 now contains the core framework implementation and validation, could we coordinate by keeping this PR for the inspect-robots hook while you continue the KitchenBench task and version migration in #29 against it? @jeqcho, I’m happy to follow your preference if you want the ownership structured differently.

[Adityakk9031]

please close this