Audit follow-ups: lru advisories, and hailo-backend-audit.yml has drifted from .cargo/audit.toml

Three follow-ups from the RUSTSEC-2026-0258 (h2) fix in #913, which is merged and took cargo audit from exit 1 ("2 vulnerabilities found") to exit 0.

1. lru 0.12.5 — fixable, but needs a TUI migration

RUSTSEC-2026-0253, lru, UNSOUND — "Potential use-after-free due to lack of panic safety in LruCache::pop()". Advisory is patched = [">= 0.18.2"], unaffected = [] — no backport to the 0.16.x or 0.12.x lines.

ratatui 0.30 drops the lru dependency outright, which clears this. But 0.29 → 0.30 also forces crossterm 0.28 → 0.29 and the 0.30 restructuring into ratatui-core/ratatui-crossterm (moving backend::CrosstermBackend), which reworks a ~420-line rvagent-cli/src/tui.rs.

Deliberately not bundled into a CI-unblocking dependency fix.

2. lru 0.16.4 — not fixable by a bump; blocked upstream

lattice-embed pins lru ^0.16.3 at every published version, including the latest 0.9.0 (we are on 0.6.1). ^0.16.3 can never resolve to 0.18.2.

Mitigating: it is optional, behind ruvector-core's opt-in lattice-embeddings feature (which also raises MSRV to 1.93), so it is not in a default build. Blocked on lattice-embed upstream.

Neither lru advisory is currently failing CI — supply-chain.yml runs plain cargo audit without --deny warnings (a documented choice: "Using --deny warnings would double-count what deny.toml already triages"), so UNSOUND advisories surface as warnings and cannot fail the job. No ignore entry was written for either, per .cargo/audit.toml's own policy that fixable advisories get bumps rather than ignores.

3. hailo-backend-audit.yml has drifted — will fail when next triggered

That workflow runs cargo audit --deny warnings with a short inline ignore list that predates several current advisories, RUSTSEC-2026-0253 among them.

Because --deny warnings is on there, the lru UNSOUND warning will fail it — along with several others. It is path-filtered to the hailo crates and last ran 2026-08-03, so it is not red today, but it is a latent failure waiting for the next hailo-touching PR.

It has diverged from the central .cargo/audit.toml policy. Either point it at the shared config or reconcile its inline list.

Context worth recording: the advisory that was believed to be failing CI (lru) was not the one that actually was (h2). The cargo audit output shows lru in a Warning: unsound block immediately above error: 2 vulnerabilities found!, and the two are unrelated — the errors were both h2. Worth reading the verdict lines rather than the nearest advisory ID.

Start by comparing hailo-backend-audit.yml with .cargo/audit.toml and review the workflow's cargo audit --deny warnings invocation. Determine whether the workflow should use the shared config or reconcile its inline ignores, then trigger or run the hailo audit to verify it no longer fails because of known advisories.