quickstart's key-generation path writes a header nothing reads; firmware built by the documented procedure keeps the RFC test key #141

docs/quickstart.md § Signing Firmware Images tells a developer:

# Generate an Ed25519 keypair (first time only).
# Writes keys/private.pem, keys/public.pem and keys/public_key.h.
python3 sign_image.py --genkey --output keys/

keys/public_key.h defines static const uint8_t ebldr_default_pubkey[32]. That symbol has zero consumers:

$ git grep -n ebldr_default_pubkey
core/image_verify.c:177:   * symbol directly. Two reasons: ebldr_default_pubkey was never
tools/sign_image.py:343:static const uint8_t ebldr_default_pubkey[32] = {{
tools/sign_image.py:381:static const uint8_t ebldr_default_pubkey[32] = {{

core/image_verify.c's own comment records that it "was never defined anywhere, so this did not link", and the verifier was changed to read the anchor from the keystore. The keystore's production slot is ebldr_production_key[], generated at configure time from -DEBLDR_PRODUCTION_KEY=<64 hex> (see docs/key_lifecycle.md, #122). Nothing includes public_key.h.

So a developer who follows the documented procedure generates a key, gets a header, builds, sees no error, and ships firmware whose trust anchor is still the RFC 8032 §7.1 TEST 1 public key — whose private half is printed in a public IETF document. .ai/security.md: a weaker posture must be documented, not silently pretended strong. Here the documentation asserts the strong posture.

--extract-pubkey writes the same dead header. Raised as finding 2 (High, P1) in the automated review of #116 at ef5b70d, which also checked that #122 does not close it: after the whole stack lands the repo would document two key paths, one of which does nothing.