enhance(spec-phase): edge-probe precision probe should name tie-breaking / rounding-mode (#1108)

* feat(spec-phase): name tie-breaking/rounding mode in the edge-probe precision probe (#1102)

The precision edge probe fired on numeric-range requirements but its text never
named the most common rounding failure mode — tie-breaking / rounding mode
(half-up vs half-to-even, ceil/floor/truncate). In an A/B experiment the weak
tier (haiku) false-passed 50% of tie-class defects against the surfaced-
unresolved spec; naming the rule in the probe text drove honest abstention
83%→100% (false-pass 17%→0%, haiku 50%→0%) with no category regression
(precision still fires only on numeric-range).

Sharpen the single TAXONOMY probe string and update every rendering together so
the doc↔fixture↔machine contract (edge-probe-docs-fixtures.test.cjs) stays green:
src/edge-probe.cts, the edge-probe.md taxonomy table + 2 worked examples, the
01-round-half-even and 04-money-rounding fixtures, and the resolve-edge-coverage
how-to. Prose-only — no consumer keys on the probe text; SHAPE_CUES firing
unchanged; fully backward compatible.

* chore(changeset): Changed fragment for edge-probe precision probe text (#1108)

docs/how-to/resolve-edge-coverage-findings.md

@@ -12,7 +12,7 @@ For the category taxonomy and the reasoning behind front-of-pipeline edge analys
 
 Each finding is one **applicable** edge for one requirement — a boundary the probe's relevance filter decided is in scope for that requirement's shape, and that you have not yet addressed. A finding is phrased as a probe question, for example:
 
-> **R3 · precision** — Where can precision loss or overflow occur, and what is the contract?
+> **R3 · precision** — Where can precision loss, overflow, or rounding/tie-breaking occur — and what is the exact contract (e.g. half-up vs half-to-even, ceil/floor/truncate)?
 
 You must resolve each finding into exactly one of four states. Claude presents them as a numbered choice (or an `AskUserQuestion` menu).