docs(supply-chain): record why RUSTSEC-2026-0222 cannot be triggered here

[h4x0r]

The existing reason said only that no yara-x release resolves to a patched
wasmtime. That is true, and it is the weaker half of the story: it argues we are
stuck, when the accurate claim is that we are not affected.

Reading the advisory rather than its summary line:

"This bug is not triggerable by guest WebAssembly programs. It requires
 the embedder to create two `Engine`s and mix objects between them."

blazehash is not the embedder. yara-x is, and it holds exactly one engine for
the whole process:

yara-x-0.9.0/src/wasm/mod.rs:726
pub(crate) static ref ENGINE: Engine = Engine::new(&CONFIG).unwrap();

A single lazy_static Engine means there is no second Engine whose type indices
could be confused with it, so the cross-engine lookup that this advisory
describes cannot occur. Verified identical in yara-x 0.12.0, which issen
resolves, so the same reasoning covers that repo.

This matters for review quality, not just tone. "Cannot upgrade" invites the
reader to re-check whether an upgrade has appeared. "Precondition structurally
unreachable" is a claim they can falsify directly — by grepping yara-x for a
second Engine — and the removal condition now names that case explicitly
alongside the upgrade one.

The unavailability of an upgrade is kept, since it is still true and still the
reason the vulnerable version sits in the lockfile at all: resolved wasmtime is
25.0.3 via yara-x 0.9.0; patched lines are 24.0.12+/36.0.13+/46.0.2+/47.0.3+;
the latest yara-x (1.19.0) requires ^43.0.2, which is not one of them.

Severity for the record: CVSS 3.8 Low, AV:L/AC:H/PR:H/UI:R — local access, high
attack complexity, high privileges, user interaction.

Comment-only change to deny.toml plus the one-line reason string.
cargo deny check advisories still passes.