Doc-vs-code contradictions in published files: stale step numbering, advisory logging, dot-path rejection

[F-e-u-e-r]

Summary

Three doc-vs-code contradictions in published files (not the gitignored
staging zone) surfaced while distilling the skill-vetting hardening campaign into
a project-skill library. In each case the CODE is authoritative and correct; the
prose overstates or mis-numbers. Grouping them into one issue per the "prefer one
consolidated issue" convention.

All line numbers are against HEAD 79ca49c; re-confirm before editing.

(a) Stale step numbering in skills/skill-vetting/SKILL.md

• :48 says the opening digest matches "the one at step 5" — the closing
  digest is step 6 (off-by-one; a step was inserted without updating this
  back-reference).
• :216 says the steps "put the read first and the digest last" — this predates
  the inserted step-2 opening digest, so it now mis-describes the sequence.

The authoritative sequence is the numbered steps with the two-matching-digests
bracket (opening at step 2, closing at step 6). Fix both references to match.

(c) Advisory logging presented as guaranteed/auditable while _log is best-effort

• reviews/2026-07-25-skill-vetting-snapshot-threat-model.md:296 (invariant I6)
  states the advisory action "is logged"; README.md:429 and
  README.zh-Hant.md:268 present the advisory log as an auditable guarantee.
• But hooks/skill-vetting-advisory.py _log (def :120) swallows all
  exceptions at :149-150, so logging is best-effort — a failed write is
  silently dropped and the advisory still proceeds.

Either soften the docs to "best-effort" or make the log write failure-visible.
The invariant wording and both READMEs should agree with the code.

(d) Dot-path rejection overstated in prose and CLI error

• skills/skill-vetting/SKILL.md:140 and the CLI error string at
  hooks/skill_snapshot.py:930 imply that every .. spelling is refused.
• The code actually refuses on arrival evidence, not spelling: a .. that
  resolves to the current non-symlink $PWD passes (this is correct behavior).

Reword both to describe the arrival-evidence predicate rather than a blanket
"any .. is rejected", so the doc does not promise a stricter rule than the code
enforces.

Secondary (lower priority, in-code docstring only)

hooks/skill-vetting-advisory.py:205-210 docstring says a concurrent lost delta
is "un-recorded and never re-advises" (:209), which overstates the
current-content case against the executable is_changed path. The threat model
I11 (:279-283) says "un-recorded / a lost update", which is correct — so this is
a docstring-wording fix, not a threat-model change. Included for completeness;
can be folded into the same doc pass.

Why file rather than fix in place

These live in tracked, published files outside the staged delivery's allowed diff
boundary (skills-staging/2026-07-30-security-enhancement/ only). Reporting for an
upstream fix keeps the delivery within scope. The staged UNCERTAINTY.md records
all four as known live-doc defects with safe defaults.