docs(security): plan the next hardening waves

[BitHighlander]

Summary

• records the next security-hardening wave against exact develop baseline 21d6a9d100b16566a1e48899abbbb7bab9366187
• assigns the eleven audited gaps to immediate firmware work, migration-sensitive work, protocol research, or a future hardware revision
• defines merge and release-evidence gates, including negative controls and direct test-binary status
• proposes an OTP-backed unary security epoch for anti-rollback

Why anti-rollback is an RFC, not an application patch

An application-only version check would be mutable by the older signed image it is meant to reject. The floor must be enforced by the bootloader and backed by irreversible state. The STM32 OTP source assignments do not prove that an apparently unused block was never programmed by factory tooling, so this RFC requires a manufacturing audit before reserving a block.

Review decisions requested

• confirm the threat model and delivery order
• audit OTP usage across every factory image and board revision
• decide unsigned-firmware behavior once a security floor is active
• identify owners for the bootloader rollout and destructive/power-loss hardware campaign

Validation

Documentation-only change; Markdown and whitespace checks pass.

Related work

• fix(signing): reject BIP86 change output with a non-taproot script type #333 remains the separate Taproot-enabled release blocker
• fix(reset): stop displaying internal entropy #336 removes the internal-entropy display path
• feat(storage): version PIN KDF hardening #335 prototypes the versioned PIN-KDF migration and remains blocked on the downgrade gate