docs: correct the container scan write-up and record the August findings

[bgard68]

Documentation caught up with two rounds of changes to the container scan, plus the August dependency work written down as a troubleshooting order.

The one that was actually wrong

docs/development/security-remediation.md said under M10:

Trivy reports rather than blocks: base-image CVEs appear and are fixed on Microsoft's schedule, not ours, so failing the build would just train everyone to ignore a red X.

That stopped being true on 2026-08-02, when #60 turned the gate on — because ignore-unfixed: true makes the argument collapse. Trivy drops everything without a patch, so whatever it still reports is fixable by definition. The sentence survived that change and a second one on 2026-08-17, sitting in the place a reader hits first. Exactly the drift shape check-docs-drift.sh was written for, which it did not catch because it was not on the list.

It is on the list now, negative-tested both ways:

1. as-is                              exit 0 — passes
2. retracted sentence reintroduced    [FAIL] ... still claims: the container scan
                                      reports without blocking
3. removed again                      exit 0 — passes

What each document gained

docs/development/security-remediation.md — M10 now records that Trivy blocks and since when; that severity: CRITICAL,HIGH never applied while the gate hung off a format: sarif step (trivy-action logs Building SARIF report with all severities); that failing the scan skipped upload-sarif, so the Security tab got results only on runs with nothing to report; and that digest pins need refreshing as routine maintenance, which is how CVE-2026-62901 (HIGH, .NET DoS) sat unpatched until the weekly scan went red and blocked 22 pull requests.

SECURITY.md — said the scan blocks without saying on what. Now states the CRITICAL/HIGH scope, that lower severities still reach the Security tab, and why that scope is trustworthy: gate-probes.yml parses the workflow and rejects a gate built on a SARIF-format scan.

docs/lessons.md — two new subsections under security scanning, plus six entries in the quick index. Ordered by what would have saved the most time first: a required check red on the base branch blocks every open pull request behind it.

docs/development/dependency-audit.md — §5, a worked example matching the existing Vite 8 / Vitest 4 one. The NU1004 lock-file problem, the codeql-action sub-action pairing, the nanoid advisory, and the caveat that npm audit fix also stripped libc metadata from six optional platform packages — unrelated churn inside a security fix.

Two Dependabot behaviours worth having written down

• @dependabot rebase can be a silent no-op. It replies "already up-to-date" when its change still applies cleanly, which is not the same as containing your base commits. Both build(deps-dev): bump @testing-library/user-event from 14.6.1 to 14.6.4 #104 and build(deps-dev): bump vite from 8.2.0 to 8.2.1 #105 reported up-to-date while sitting 2 commits behind and still carrying the vulnerable nanoid 3.3.16. @dependabot recreate is what actually rebuilds.
• Check results belong to a commit, not a branch. Merging a fix into the base does not turn a stale red X green — and here that mattered: those two branches displayed checks from a week earlier while their content would have reverted the nanoid fix.

Verification

./scripts/check-docs-drift.sh — 6 passed, 0 failed. Every path cited exists, no known-false claims, and all four promised controls are present in the code.

🤖 Generated with Claude Code