docs: the skill and the README caught up with 0.7.0

Three published documents went out with 0.7.0 unread.

SKILL.md told a reader what a SKIP FINDING means and stopped there.
Complete before 0.7.0, not now: a repo can headline `OK · 3 not
checked`, and a session reporting the status word alone would report a
green pass over three unjudged findings. Status and count are now
required together. Shipping without this made the plugin whose purpose
is catching stale published documents ship one.

README's example output cited commits older than the behaviour they
demonstrate — 5884a64 (0.6.0) beside a `notChecked` that did not exist
in it, and a7276e6 two releases back. The version names a file; only the
sha names the code. Both now cite 10ad125.

README also now states the unit: `notChecked` counts un-judged FINDINGS,
not checks. portfolio-optimiser's `11 not checked` is almost entirely
LINK-OUTSIDE-REPO, so the bare number reads worse than the repo is. Named
as a known limitation, not corrected in the string — the fix is splitting
"deliberately not judged" from "could not run", which is the next release.

skills/repo-standard/SKILL.md

@@ -34,6 +34,13 @@ register against the live org listing.
 to judge — an unreachable forge, an untagged repo, a link leaving the
 repository. Say which.
 
+That applies hardest when the repo's own status is green. Since 0.7.0 a `SKIP`
+no longer outranks an `OK` in the status line, so a repo reads
+`OK · 3 not checked` rather than `SKIP`. The number is the qualifier: three
+findings nobody judged. Report the status and the number together, never the
+status alone, and name what went unjudged — the detail output lists them under
+`NOT CHECKED`.
+
 **Confirm the version before you trust a green run.** Measured 2026-08-04:
 `${CLAUDE_PLUGIN_ROOT}` resolved to a cached `0.1.1` in a live session while
 `0.2.0` was installed and the catalog pinned it — same instruction, same