chore(guardrail): re-sync canon, id no longer moves with the calendar

[fas89]

Routine vendored-guardrail re-sync. Two files moved, both of them travelling
files that are identical in every repo of this class: canon_payload.py and
check.py.

What moved

compute_canon_id now excludes the payload's Emitted <date> line from the
digest, alongside the CANON_ID line it already excluded.

Why

The emitter stamps today's date into the payload, so while that line was
hashed the canon id was a function of the calendar, not of the vocabulary.
Re-emitting with no vocabulary change at all moved the id; every vendored copy
then read as out of date; and the daily fan-out asked for one pull request per
product repo that would have changed a date and nothing else. Measured on
2026-09-15, the canonical payload and forge-cli's vendored copy differed in
that line alone, and in the id it forced.

The id now answers "is this the same vocabulary", which is the only question
anyone asks it.

The exclusion is deliberately narrow. _EMITTED_LINE is anchored to a bare
ISO date (^Emitted \d{4}-\d{2}-\d{2}\.$), not to ^Emitted, because a line
excluded from the digest is a line nobody checks: Emitted 2026-09-15. FooBrand is fine now. does not match the pattern and is still hashed.

check.py --self-test gains an assertion in both directions, since an
exclusion that is too wide is as dangerous as a missing one: re-dating the
payload must not move the id, and appending any other line must.

Verified in this checkout

Check	Result
check.py --self-test	exit 0 — 15 entries both ways, 8 extractor specimens
check.py	exit 0
scan	scanned 68 files, 292206 bytes, 447 spans, 3 rules
findings	canon holds: 0 failing findings, 0 warning(s), 0 graced.
CANON_ID	ff28e99a952b791210cf743af8eecb3117f5cdd51f0f92710061b72dd8ff0330 — the public redacted variant, as expected for this repo
len(DEFINITIONS)	0 — the maturity ledger is redacted from public payloads, as it must be

The scan reports 0 of 10 approved names present under canon coverage. That is
expected for an SDK repo whose prose does not name the product surface; it is
coverage information, not a finding, and the scan exits 0.

Not touched

tools/product_guardrail/profile.py is untouched, and git status was
checked for it explicitly before committing. It is hand-written per repo — what
to scan, what to skip, the grace list — and it never travels. The diff is two
files, both generated upstream.

Not merging from here; this is for review in the usual place.