Coverage baseline auto commit-back — CI persists/ratchets the baseline (opt-in, on top of #282)

[rucka]

Story Statement (DRAFT — very low priority)

As a team using the (opt-in) coverage guardrail
We want the CI to automatically commit back the coverage baseline (persist + ratchet it up as coverage improves)
So that the baseline self-maintains without a manual commit each time coverage rises.

Context

Builds on #282, whose default is model A: a human-committed baseline (the auto-bootstrap only suggests a value; a human commits it to make it an effective floor). This story adds the optional automation (model B): a CI step that commits the updated baseline back into the repo so it persists across runs and ratchets upward.

Why very low priority

Model A (human-committed) already makes the guardrail correct and effective. B is a convenience (no manual bump) and is stack/CI-specific and non-trivial: needs a write-scoped token, a bot commit, PR-vs-main handling, and loop-avoidance (a commit re-triggering CI). Not needed for the guardrail to work.

Scope (to refine)

• Opt-in CI commit-back of tech/risk-matrix-style baseline in coverage-baseline.md.
• Stack-agnostic guidance + a reference implementation for the default stack; token/permissions + loop-avoidance documented.
• Must remain opt-in on top of the opt-in coverage guardrail (double opt-in): default stays human-committed (A).

Acceptance Criteria (to refine)

• When enabled, a CI run that raises the baseline commits the new value back; the commit does not re-trigger an infinite CI loop.
• Default unchanged (A / human-committed) when not enabled.
• Token/permission + PR-vs-main behavior documented.

Status / Priority

Draft — NOT refined. Priority P3 (very low). Pick up only after the higher-value quality/automation work; A covers the need in the meantime.