Step output contract v2: structured data payloads alongside markdown for every builtin

[hartsock]

Feature

Reports are read by humans AND consumed by agents. Markdown sections serve the human; every step should ALSO populate its StepResult.data with a stable, documented JSON shape so agents stop parsing prose.

Proposed shape

• Define a per-step-type data schema (documented in each step's rustdoc + a steps_list extension exposing the schema), starting with the builtins: git steps (per-repo status enums, not strings), deadline/countdown (numeric days/els), review queues (item arrays), reminders (typed records — already close).
• Schema stability rule: data shapes are versioned with the crate; breaking a shape is a breaking change with a regression test proving the old shape fails loudly.
• format: \"data\" option on routine_run/step_run/report_get: returns ONLY the structured payloads (compact), for agent consumers that never want prose.
• Acceptance: an agent can run the full morning routine and act on every section without one string-match against markdown.

Development discipline

Rust-first, jujutsu-style (no panics in lib code, RFC-1574 doc comments, lower-level tests over e2e). Follow Foundation contributor rules + the rust-tdd skill: TDD, regression tests, 80% coverage floor, README per crate, exec/net leashed, generation counters not wall-clock, credentials as references only. Plugin model per #10.

[hartsock]

Testing-strategy addendum from the F1 CI regression: the suite is layered (mocked logic / real-seam / real-wheel pytest), and the remaining gap — mock fixtures encoding unverified beliefs about external CLI output shapes — is now specced as F1.5 live-contract tests (opt-in, MODULEX_LIVE_TESTS=1): see the new issue above. F5's authoring guide will prescribe the three tiers for every plugin.