fix: ci: stop check-canon failing on the 2026-05 audit record it cannot rewrite

[srpatcha]

Problem

check-canon has failed on every run since 2026-05-19 and has never been
green since. Its last success was run
25777395642
on 2026-05-13; every run after that is a failure, including the ones on
master (26149265404,
26148951962,
26127809462)
and the most recent one,
32614652320.

Running scripts/check-product-canon.py against origin/master reports 26
forbidden references. All 26 are inside audit-2026-05/, and the great
majority are in lines that name the deprecated repos precisely in order to ban
them:

audit-2026-05/per-repo/eos.md:40  ->  eHardware-Designs-Products (renamed -> eCAD-Hardware-Products)
    - [ ] No reference to deprecated repo names (`eHardware-Designs-Products`, etc.)
audit-2026-05/README-contract.md:50  ->  eVera (dropped product)
    - References to dropped products (`eVera`, `eStocks`, `eHardware-Designs-Products`) outside the explicit canon exception in `docs/embeddedos-ecosystem-guide.md`
audit-2026-05/per-repo/eVera.md:1  ->  eVera (dropped product)
    # eVera — audit checklist

Root cause

audit-2026-05/ landed on 2026-05-19 in d5580a1 and 8c2838c — the same day the
lane went red, and it has stayed red ever since. That directory is the dated
record of the rename the validator enforces: the per-repo checklists tell a
maintainer to remove the old names, README-contract.md defines what counts as
a violation, session1-summary.md logs what was done, and
per-repo/eVera.md exists because eVera was audited before it was dropped.
The validator has no way to tell "this file uses the old name" from "this file
is the instruction to stop using the old name", so it flags the audit for
containing the very strings that make it an audit.

Fix

Add audit-2026-05/ to EXCLUDE_PATH_FRAGMENTS in
scripts/check-product-canon.py, alongside the exclusions that already exist
for exactly this reason:

# Archival book/long-form sources that intentionally document historical
# products. These compile to PDFs and are not user-facing canonical surfaces.
'docs/embeddedos-ecosystem-guide.md',
'CHANGELOG.md',

Both separator spellings are listed, matching how tests/screenshots and the
ecosystem guide are already handled for Windows checkouts.

The alternative — editing the old repo names out of the 2026-05 audit — was
rejected: it would make a dated compliance record say something it did not say
in 2026-05, and per-repo/eVera.md cannot be corrected at all, because its
subject is a product that no longer exists.

Files changed

• scripts/check-product-canon.py — seven lines added to
  EXCLUDE_PATH_FRAGMENTS (five of them the comment). No logic changed.

Expected impact

check-canon goes green on master for the first time since 2026-05-13, so
the next real canon regression is visible instead of arriving into an
already-red lane.

Risks and compatibility

• This narrows the check. The scanned set drops from 36 files to 7; the 29
  excluded files are all under audit-2026-05/. A future canon violation added
  inside that directory would no longer be caught. That is the deliberate
  trade, and it is the reason this is opened as a draft rather than as a
  routine fix — if the intent is for the audit directory to stay under the
  validator, the correct answer is to move it somewhere it is unambiguously
  archival, not to keep the lane red.
• The check still bites everywhere else. A probe file carrying eVera placed
  at the repo root is still caught and still fails the run; that is recorded
  under the canon-still-bites check below, with the offending path named in
  its output.
• No workflow file, no CI trigger and no forbidden-pattern list is touched, so
  nothing about what the validator looks for changes — only where it looks.
• lint-readme is also red, and it is red on the same directory: its
  lychee job fails on the link ../../C:/Users/spatchava/.llms/plans/production_readiness_20_repo_audit.plan.md,
  which every audit-2026-05/per-repo/*.md carries, and 369 of its 469
  markdownlint errors are under audit-2026-05/ as well. This PR does not
  address lint-readme: lychee and markdownlint have their own ignore
  mechanisms, and 100 of those markdownlint errors are outside the audit
  directory, so that lane stays red either way. It is recorded in the sweep
  backlog separately.

Surfaced by the maintenance sweep scan
state/maint/20260906T013056/.github.md, §"CI — latest run on master".

Verification

Executed in an isolated worktree branched from origin/master:

Check	Result	Duration	Command
canon-still-bites	pass	0s	python3 /tmp/check_canon_still_bites.py
check-canon	pass	0s	python3 scripts/check-product-canon.py

---

Opened by the scheduled autoreview pipeline (model claude-opus-5), branched from origin/master. No human has reviewed this yet. Close it freely if the fix is wrong - a bad automated PR is a bug worth reporting.

Fixes #4