feat(model): a bound on the data lowers the rung, it does not clear it

contributor-scan 2.12. c/injection and c/memory carried zero sanitizers,
so no C flow could ever be discharged: every `argv -> strcpy` entailed
however carefully it was bounded.

Which sinks can be discharged this way is read from the sink fact's own
CWE rather than declared: CWE-121 is a stack buffer overflow, so
gets/sprintf/strcat/strcpy qualify. It is the only overflow CWE in the
fact tables and it is C-only, so no Python or JavaScript sink is touched
and the pair corpus is unaffected -- gates byte-identical.

Not a sanitizer list, because `strlen` appears in the guarded and the
unguarded case alike; the discharge is a guard, not a call.

**The first implementation required the bound to DOMINATE the sink, and it
found nothing.** libpng guards `strcpy(outname+len, ".png")` with
`(len = strlen(inname)) > 250`, but that check sits on an else-if chain
whose sibling branch skips it entirely, and the protection reaches the
sink through an `error` flag: `++error` in the guarded branch, `if
(!error)` around the copy. Joern's dominator set for that sink has 89
calls and correctly excludes the bound; `controlledBy` returns none
either. Verified against the CPG before the rule was changed rather than
after it failed.

So the bound is searched in the method, and the consequence is
corroborated rather than silence. That is the honest rung: a bound on this
variable means the graph has NOT shown the copy is unguarded, and it has
not shown it is guarded either -- off-by-one being how bounds fail. The
judge is asked. Proving the flag-mediated case needs path-sensitive
reasoning this arbiter does not do.

  libpng entailed   3 -> 1

The survivor is also a false positive: `strcpy(output + len, ".icc")` in
iccfrompng.c, where `output = malloc(len + 5)` makes it fit exactly. That
is a different discharge shape -- allocated to size, not bounds-checked --
and it is recorded as 2.13 rather than chased. Both shapes were found on
one repository, and extending a rule until that repository is clean is the
overfitting Req 8 exists to prevent; 2.13 requires a second C checkout
with a genuine CWE-121 so the change can be measured for what it silences
as well as what it clears.

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

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

@@ -221,7 +221,7 @@
   - _Requirements: 4.2, 8.1_
   - _Depends: 2.2_
 
-- [ ] 2.12 A C flow that a bounds check governs is not a finding
+- [x] 2.12 A C flow that a bounds check governs is not a finding
   - `c/injection` and `c/memory` carry ZERO sanitizers, so no C flow can ever be discharged. Every
     `argv -> strcpy` entails however carefully it is bounded, which is why libpng reports
     `strcpy(outname+len, ".png")` at wpng.c:374 -- guarded four dozen lines earlier by
@@ -235,6 +235,20 @@
   - _Requirements: 8.1, 8.2_
   - _Depends: 2.9_
 
+- [ ] 2.13 A destination allocated to size is bounded too
+  - 2.12's remainder, and libpng's last entailed finding: `strcpy(output + len, ".icc")` at
+    contrib/examples/iccfrompng.c:124, where `output = malloc(len + 5)` and a five-byte copy lands at offset
+    `len`. It fits exactly. There is no comparison anywhere, so the bound rule cannot see it -- the
+    destination is ALLOCATED to size rather than bounds-checked.
+  - Deliberately not done inside 2.12. Both discharge shapes were found on the same repository, and
+    extending a rule until one checkout is clean is the overfitting Req 8 exists to prevent. This wants a
+    second C checkout with a genuine CWE-121 first, so the change can be measured for what it silences as
+    well as what it clears.
+  - Observable: iccfrompng.c:124 not entailed, AND a real overflow on another checkout still entailed.
+    Without the second half this task should not be closed.
+  - _Requirements: 8.1, 8.2_
+  - _Depends: 2.12, 5.3_
+
 ## Group 3 — Ship it
 
 - [ ] 3.1 Contributor output