prod-feature-check: the #705 OVP experiment features are not in PROD_FORBIDDEN, and the denylist covers only 1 of 3 firmware crates

[Nicola-Ceornea]

Two gaps in the mechanical production-feature policy, found by a dev-instrumentation
sweep. Both are about the denylist's coverage, not about a specific leak — the
three actual mis-gated diagnostics it found are fixed in 17cef45c.

Filed rather than fixed here because Makefile is currently being edited by
another session in this worktree.

G1 — the two #705 OVP experiment features are not in PROD_FORBIDDEN

Makefile PROD_FORBIDDEN (~line 2575) lists ~35 never-ship features. It does
not list:

• aw99703-ovp-low — programs the backlight boost's over-voltage threshold down
  to OVPSEL=000 (16 / 17.5 / 19 V) instead of the shipping 001
  (22.5 / 24 / 25.5 V)
• aw99703-full-brightness — drives the backlight at full scale instead of the
  0x5FF the product ships

Both are guarded today only by compile_error! on mode-production in
secure/src/nsc/mod.rs. That is exactly the hole the denylist exists to cover:
the list's own comment records that a release built without mode-production
previously slipped every gate.

These are not cosmetic flags. They change the trusted display's own drive —
the over-voltage protection threshold on a boost whose output capacitor is rated
25 V, and the brightness of the screen the user reads confirmations on. A build
that shipped with aw99703-ovp-low on would run the panel at a protection
threshold chosen for a bench experiment.

Fix: add both names to PROD_FORBIDDEN. Two words.

G2 — prod-feature-check covers one of three firmware crates

The check resolves -p sphincs-tz-secure only. Neither pqsigner-fsbl nor
sphincs-tz-nonsecure is covered by any denylist.

Severity is genuinely low and should not be overstated:

• The FSBL has in-source fences — fsbl/build.rs panics on
  mode-production && lcd-test, and marker.rs fences stage-marker.
• The non-secure world holds no secrets by invariant fix(wallet): gate owner add/remove on the EntryPoint, not address(this) #4.

But the mechanical policy — the thing that catches what a human reviewer
misses — currently covers one crate out of three, while the FSBL is the crate
invariant #10 makes permanently unpatchable after the RDP-2 self-lock. A
diagnostic that reaches a frozen FSBL cannot be removed later by any update.

Fix: extend prod-feature-check to resolve all three crates, or add
per-crate denylists.

Latency on both

Neither is urgent. No shipping image can be built at all right now:
secure/build.rs panics FW_ROLLBACK_PRODUCTION_BLOCKED on every
thumbv + stm32u585 + mode-production build, fsbl/build.rs mirrors it, and
make release / make fsbl-release are both $(error).

These should be closed before that rollback quarantine lifts, since that is
the moment the denylist starts being the thing standing between a bench feature
and a shipped device.

[Nicola-Ceornea]

G1 is dissolved by 652c9b5d: aw99703-ovp-low and aw99703-full-brightness have been removed outright (owner decided to keep OVPSEL=001, so the experiments' question is answered). With the features gone there is nothing for PROD_FORBIDDEN to deny, which is a better outcome than adding two names to the list.

G2 stands and is the reason this issue stays open: prod-feature-check resolves -p sphincs-tz-secure only, so neither the FSBL nor the non-secure crate is covered by any denylist — and the FSBL is the crate invariant #10 makes permanently unpatchable after the RDP-2 self-lock.