docs(kbn): downgrade the -05 Dockerfile finding to unresolved planned-vs-current

Scrappy's ruling, verified independently at
docs/scratchpads/771-kbn101-db-role-split.md:98, which records
apps/gateway/Dockerfile explicitly as 'a planned KBN-101-05 artifact'.
The row names something intended to exist, not a mis-naming of
docker/gateway.Dockerfile, so it is not the inverse defect I filed it as.

The correction sharpens the proposed control: a link check failing on any
absent ownership path would have flagged this row and been wrong. The
check needs a planned marker, and an unmarked absent path is the failure.

Negative existence evidence retained; classification corrected.

docs/native-kanban-sot/KBN-101-DB-ROLE-SPLIT.md

@@ -517,12 +517,27 @@ Compose/stack ownership. Every named capability lands in a scope row that contai
 
 **Finding 4 — structural.** None of these claims is machine-checkable. Nothing links "capability
 named in a guide" to "capability present in an item's criteria", which is why the `-02` gap
-survived review at eight sites. The inverse form of the same hole is live in this document: the
-`-05` rows name `apps/gateway/Dockerfile`, which does not exist — the image source is
-`docker/gateway.Dockerfile`. An ownership row pointing at no file and a hold pointing at no
-criterion are one defect class, and both are green against every check currently run.
+survived review at eight sites.
 
-Suggested control, for every lane rather than this one: a link check that resolves each
-`held until <ITEM>` claim to a scope row or AC containing the named capability, and each ownership
-row to a path that exists, failing CI on an unresolved claim. `-02a` does not implement it; the
+A related observation, **downgraded on review and recorded at its corrected strength**: the `-05`
+rows name `apps/gateway/Dockerfile`, and no such file exists (the current image source is
+`docker/gateway.Dockerfile`, 1996 bytes). An earlier revision of this audit called that the inverse
+form of the same defect. That was wrong, and the correction is the more useful finding.
+`docs/scratchpads/771-kbn101-db-role-split.md:98` records the path explicitly as "a planned
+KBN-101-05 artifact", so the row names something intended to exist rather than mis-naming something
+that does. The status is **unresolved planned-versus-current ownership** — which of the two paths
+`-05` ultimately owns is a disposition for that item, not a typo for anyone to correct. The
+negative existence evidence stands; the defect classification does not.
+
+That correction sharpens the control rather than weakening it. A naive link check that failed on
+any ownership row whose path is absent would have flagged this row and been wrong, because a
+planning contract legitimately names artifacts that do not exist yet. So the check has to
+distinguish the two, and the cheapest way is to make the document say which it means: an ownership
+row naming a path that does not exist must mark it **planned**, and an unmarked absent path is the
+failure. Without that marker there is no way to tell a forward-looking row from a stale one, which
+is precisely the ambiguity this finding walked into.
+
+Suggested control, for every lane rather than this one: resolve each `held until <ITEM>` claim to a
+scope row or AC containing the named capability, and each ownership row to either an existing path
+or an explicit planned marker; fail CI on an unresolved claim. `-02a` does not implement it; the
 finding is filed for the integration gate.