docs(621): state the mutation count precisely — it depends on which mutation

The record said "10 tests go red"; on the rebased base a full short-circuit reddens 11.
Both numbers are real and measure different mutations: neutering only the scan loop
leaves the empty-wing check live (10), while returning [] from the whole function
disables that too (11). The reviewer flagged the phrasing as ambiguous before the count
also drifted.

Now states the mutation alongside the number, since a bare count is exactly the kind of
frozen figure this session has watched rot four times.

Refs #621

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/decisions/records/docs/record-wing-parse-guard.md

@@ -48,7 +48,8 @@ hole rather than creating it. Teaching `_read_frontmatter` to fold block scalars
   single-**line**, not single-**quoted**: 117 `rule:` values are unquoted plain scalars, 51 are
   quoted.) There is no value a flat scalar cannot hold.
 
-Verified by mutation, not by a green tick: with `record_wing_faults` neutered, **10** tests go red,
+Verified by mutation, not by a green tick: with `record_wing_faults` short-circuited to return `[]`,
+**11** tests go red (10 if only the scan loop is neutered, leaving the empty-wing check live),
 and separately, deleting the single line that WIRES it into `main()` reddens a dedicated test — that
 one line's removal previously left the whole suite green while a real record vanished, which is the
 guard's own failure mode applied to the guard. `test_real_repo_record_wings_are_all_parseable` additionally asserts the