skills: correct the credential-incident-response §5 premise about chroma metadata

§5 said embedding_metadata.string_value holds "metadata fields only". False,
measured directly: chroma also stores a copy of the document text there, under
key chroma:document. Confirmed with a disposable sentinel drawer (pi@tor-ms22,
2026-08-30): one row in fts_content AND one row in embedding_metadata for the
same drawer.

This was a real mistake in shipped guidance, not a nitpick: this section's own
scanning advice was written to guard against explaining a zero with a
mechanism nobody verified from source, and the section itself did exactly
that -- I downgraded a census to "a floor" on the strength of a metadata-blind
claim I never checked against chroma's actual storage layout. The practical
scan order is unchanged (fts_content is still the direct target, raw bytes are
still the backstop); only the stated REASON for a metadata zero changes: it
needs a different explanation now (key filter, query shape, escaping), not
"structurally absent".

§6's row-gone/bytes-gone claim is upgraded from asserted to measured, same
sentinel: delete_by_source took both fts_content and embedding_metadata 1->0,
raw bytes stayed 4->4 (freed pages persist until VACUUM). Also records the
method that unblocked the measurement: not a better instrument, a disposable
sentinel drawer instead of risking real fleet data.

No image behaviour changes.

rootfs/usr/local/share/pi-devbox/skills/credential-incident-response/SKILL.md

@@ -116,14 +116,24 @@ shared palace as incident response. High blast radius, low actual benefit.
 
 ## 5. Finding a secret in a Chroma palace — three targets, in this order
 
-1. `embedding_fulltext_search_content.c0` — **where document text actually is**
-2. `embedding_metadata.string_value` — metadata fields only
+1. `embedding_fulltext_search_content.c0` — document text
+2. `embedding_metadata.string_value` — metadata fields, **and a second copy of
+   the document text** under key `chroma:document`
 3. raw byte scan of every `*.sqlite3` — backstop, covers FTS pages and free space
 
-Scanning only (2) is the classic false clean: hundreds of thousands of rows,
-zero hits, and the secret sitting in (1) the whole time. Semantic search proves
-nothing about absence — it returns top-k. For completeness, enumerate by filing
-window (`list_drawers(since=T, before=T+1m)`), since one mine shares a minute.
+**Correction, measured on chroma 1.5.9 with a sentinel drawer:** one row in (1)
+AND one row in (2) for the same drawer, so **(2) is not structurally
+content-blind** — an earlier version of this section said it held "metadata
+fields only", and that was wrong. Scan (1) and (3) regardless: (1) is the direct
+target. But if a `string_value` query returns zero for a value you know is in a
+drawer, the cause is a key filter, a query shape or escaping — *not* structural
+absence, and the difference matters because the false explanation is what makes
+the zero feel safe. See §6: do not explain a zero with a mechanism you have not
+read from source.
+
+Semantic search proves nothing about absence — it returns top-k. For
+completeness, enumerate by filing window (`list_drawers(since=T, before=T+1m)`),
+since one mine shares a minute.
 
 Value-agnostic sweeps (uuid / 40-hex / `NAME=VALUE`) drown in false positives at
 fleet scale — 608 candidates, mostly session UUIDs and git SHAs. Name-anchoring
@@ -199,10 +209,16 @@ extractor and making it look as strong as the union — a self-test artifact tha
 has already fooled an agent here. And never gate on `$?` when the tool has a
 lock-skip or no-op path that also exits 0; judge the reported line.
 
-**Row-gone is not bytes-gone.** A correct sqlite `DELETE` leaves the payload in
-freelist pages until `VACUUM`, so deletion effectiveness is *two* numbers: rows
-removed, and a raw byte scan of the `.sqlite3`. One aggregate figure reported as
-"erased" has only measured "unretrievable".
+**Row-gone is not bytes-gone.** Measured, same sentinel drawer: after
+`delete_by_source` the row count went 1 -> 0 in *both* the FTS content table and
+`embedding_metadata`, while the raw byte count stayed 4 -> 4 — sqlite does not
+zero freed pages, so the payload sits in free space until `VACUUM`. Deletion
+effectiveness is therefore *two* numbers, and each direction has a trap: one
+aggregate figure reported as "erased" has only measured "unretrievable", while a
+raw byte scan used as the acceptance gate reads a CORRECT, complete deletion as a
+failure. (Note how this was measured: the blocker was never a better instrument,
+it was the subject — file your own disposable sentinel and delete that, instead
+of testing deletion on real data.)
 
 ## 7. Choosing scopes: derive them from measured consumers