feat(reports): say what was looked for, and what cannot be decided

contributor-scan 2.16, implementing the approved Req 5.6. `c/memory`
scored zero true positives across 89k lines of C and three distinct
classes of false one, for a structural reason: it models string CALLS and
libpng overflows through arithmetic.

The task allowed retiring the family. Kept, scoped and stated instead --
`strcpy` misuse is real in plenty of C and the family earns its place for
that. Retiring it would have removed the disclosure along with the
coverage, leaving a C scan silent for a reason nobody could read.

**Its own description was the quiet-failure risk.** It claimed "bounds,
lifetime, arithmetic", which is exactly what it does not decide. It now
names the APIs it models, and a new `limits` field in families.toml says
what it cannot: an overflow expressed as an index, a pointer offset, or a
memcpy whose size is computed -- which is how most real C overflows are
written, and how every one of libpng's is.

A limit recorded in a fact table nobody reads is no better than silence, so
the report renders it. **What was analysed** lists every family offered to
a region whether or not it found anything, because a family that ran and
reported nothing is the case a reader is most likely to misread, and it
states plainly that silence means no fact table covered the code rather
than that the code is safe.

The counts are derived from the fact tables the arbiter actually used, so
they cannot drift from what the engine looked for; only the limit sentence
is authored, because "cannot decide an overflow expressed as an index" is a
statement about an abstraction and no table can produce it.

A C scan that finds nothing now says:

  | c | `memory` | 121 | 9 |
  **`memory` (c)** — Models CALLS, not arithmetic...

Gates byte-identical.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01T7XD7x5KonMdmGRkp63EQG

.kiro/specs/contributor-scan/tasks.md

@@ -294,7 +294,7 @@
   - _Requirements: 4.1, 4.4_
   - _Depends: 2.12_
 
-- [ ] 2.16 Say what `c/memory` actually covers, or retire it
+- [x] 2.16 Say what `c/memory` actually covers, or retire it
   - Its score so far is zero true positives and every finding a false one: 26 from a substring match, 3 from
     a bound it could not see, 1 from an allocation sized to fit. Each was a real defect in the engine and
     each is now fixed, but the family has never once been right, and 2.15 explains why -- it models string
@@ -304,6 +304,17 @@
     but it should be a recorded decision with a number behind it, not an assumption.
   - Observable: either a measured true positive on the 2.15 checkout, or the family's declared scope
     narrowed in the facts and the docs so no reader takes a silent C scan for a clean bill of health.
+  - **Done 2026-09-09 by the second route: kept, scoped and stated.** `strcpy` misuse is real in plenty of C
+    and the family earns its place for that; what it could not do was claim more. Its description said
+    "bounds, lifetime, arithmetic", which is exactly what it does not decide -- the description was itself
+    the quiet-failure risk. It now names the APIs it models, and a new `limits` field says what it cannot:
+    an overflow expressed as an index, a pointer offset, or a memcpy whose size is computed.
+  - The report renders it as **What was analysed**, for every family offered to a region whether or not it
+    found anything -- a family that ran and reported nothing is the case a reader is most likely to misread.
+    The counts are derived from the fact tables the arbiter used, so they cannot drift from what the engine
+    really looked for; only the limit sentence is authored.
+  - Retiring the family was the alternative and would have been wrong: it would remove the disclosure along
+    with the coverage, leaving a C scan silent for a reason nobody could read.
   - _Requirements: 3.1, 8.2_
   - _Depends: 2.15_