feat(lexicon): set hybrid severity to high, record the id space as ratified

Two things the file was waiting on arrived, and both are now data rather
than open questions.

families[hybrid].severity was null by design - the seed dump supplied the
array but not the severity. It is "high". The value is not stored anywhere
as a field: the engine assigns it by pushing HYBRID_PATTERNS matches
straight into the high bucket at injection-patterns.mjs:274-281, under the
comment "Hybrid patterns are HIGH severity (v5.0 S6)".

severity_provenance names the file it is NOT in. Both this repository and
the Python guard first looked in severity.mjs, which contains no injection-
family severity at all - grep it for any of the four pattern constants and
you get nothing. The guard's port carries the right value while citing that
file, so a consumer following its citation finds no answer. A wrong citation
to a right value survives review in a way a wrong value does not, so it is
recorded rather than quietly fixed.

pattern_id_space.not_yet_confirmed is replaced by a ratification block.
Both seeding runtimes agreed on 2026-08-09: llm-security ratified the 0.2.0
proposal as-is and treats an id change as breaking on the same terms, and
the guard confirmed the space its own port supplied. The id is a
cross-runtime contract now, which is what conformance/ needed before a
fixture could name a finding at all.

alias_evidence.llm_security is sharpened, not upgraded. All 83 alias
strings were confirmed equal to the module's label field in array order, so
the alias is certainly the pattern's name in the table. It is still not
established that a FINDING carries it: output.mjs:finding() emits title and
has no label key. Verified at table level, one level short of where it
would matter.

No detection data moved: all 83 patterns still byte-identical to the module
at b0de0ca, and no pattern entry differs from HEAD.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SNMcqrfNyoLRQ7qXUFZnb9

CHANGELOG.md

@@ -53,6 +53,30 @@ checks that were not run instead of attaching a caveat to a pass.
 
 ### Changed
 
+- `lexicon/injection-lexicon.json` **0.4.0 → 0.5.0** — the last null in the file is filled and
+  the id space is ratified. Two blockers close, no detection data moves.
+
+  `families[hybrid].severity` was `null`, deliberately, because the seed dump did not supply
+  it. It is **`high`** — and the interesting part is where that is written. The hybrid family
+  has no severity field anywhere; the engine assigns one by pushing `HYBRID_PATTERNS` matches
+  straight into the `high` bucket at `injection-patterns.mjs:274-281`. Both this repository
+  and the Python guard had first looked in `severity.mjs`, which contains no injection-family
+  severity at all. The guard's port holds the right value behind that wrong citation, so
+  `severity_provenance.not_from` records the miss explicitly: a wrong citation to a right
+  value is the harder defect to catch later.
+
+  `pattern_id_space.not_yet_confirmed` is replaced by `ratification`. Both seeding runtimes
+  agreed on 2026-08-09 — `llm-security` ratified the 0.2.0 proposal as-is and treats an id
+  change as breaking on the same terms, and the guard confirmed the space its own port
+  supplied. `id` is now a cross-runtime contract, which is what `conformance/` was waiting
+  on to be able to name a finding.
+
+  `alias_evidence.llm_security` is sharpened rather than upgraded. All 83 alias strings were
+  confirmed equal to the module's `label` field, in order — so the alias is certainly the
+  pattern's name **in the table**. It is still not established that a finding carries it: the
+  producer is `output.mjs:finding()`, which emits `title` and has no `label` key at all.
+  Verified at table level, one level short of where it would matter. Match on `id`.
+
 - `lexicon/injection-lexicon.json` **0.3.0 → 0.4.0** — verified against the source module
   instead of against the dump it was transcribed from, and **two false provenance claims
   retracted**. The source is now pinned: `b0de0ca` on the public remote, imported in Node