Composite PQC: make sign/decrypt usable, conform to draft-10, and stop reporting false success

[bmatusiak]

Brings the composite PGP-PQC path in onlykey-cli to a working, standards-conformant state.
Before this, the flow it advertises — load a PQC key, decrypt something, sign something — could
not be completed from the command line at all.

The composite functions could not return their own output

pqc.sign() and pqc.decrypt() both ended in read_string()[:N]. read_string() drops every
zero byte and returns str, and read_bytes() underneath it does a single HID read of one
report with no reassembly. So a 3309-byte ML-DSA-65 signature could never be returned — one
report's worth is the ceiling. The 32- and 64-byte cases were corrupted whenever a zero byte
appeared in the output.

Both now use a new pqc.read_exact(), which reassembles consecutive reports, skips status
broadcasts, and returns bytes. read_string() itself is untouched — 37 subcommands share it,
so this is a binary path alongside it rather than a change beneath them.

Nothing exposed those functions

setpqc/loadpqc could load a composite key and no command could then use it. Adds:

onlykey-cli signpqc    [RSA1-RSA4] [ecc|pqc] [digest hex | file]
onlykey-cli decryptpqc [RSA1-RSA4] [hex | file]

Both are deliberately device primitives: composing the two signature halves, or doing the key
combine and RFC 3394 unwrap, belongs to the caller. Operands may be given as a file path because
an ML-KEM ciphertext is 2176 hex characters, past what some shells accept in one argument.

setpqc reported success for loads the device refused

Outside config mode the device answers each of the three chunks with "Error not in config mode".
Those replies were never read, so setpqc printed "Loaded composite PQC PGP key (160 bytes) into
RSA1" and exited 0 having stored nothing. That is worse here than it sounds, because there is no
readback — okcrypto_getpubkey() has no PQC branch — so a caller had no second way to find out.
load_composite_key() now waits for the device's acknowledgement and raises on refusal, and both
subcommands exit non-zero.

Conformance to draft-ietf-openpgp-pqc-10

The vendored OpenPGP.js bridge implemented an older revision of the draft in three places:

	before	draft-10
algorithm IDs	105 / 107 (private-use range)	30 / 35
ECC key share	SHA3-256(ss ‖ ct ‖ pub)	raw X25519 shared secret
key combiner	KMAC256(…)	SHA3-256(…)

All three are corrected, and the copy in the web app is kept byte-identical.

This is a flag-day change: all three inputs feed the derived key, so any composite key or message
created before it cannot be read after. That is why it belongs before release rather than after —
afterwards it would mean orphaning real user keys.

Also included, from earlier work: two fixes to _read_response() truncating multi-packet replies,
and a refactor moving Bech32 encoding for derived identities into its own module.

Evidence

• 02-cli/17-composite-cli-ops — 8/8. The refusal is reported; both signature halves verify
  against keys derived independently from the loaded blob, including the 3309-byte ML-DSA-65 one;
  both decrypt halves match host-computed secrets.
• Interop against rpgp 0.20, an independent Rust implementation sharing no code with
  OpenPGP.js: before the conformance fix it could not parse our keys at all; after, all four
  directions pass — it parses the key, verifies our signatures, decrypts what we encrypt, and we
  decrypt what it encrypts.
• The five composite suites (30 tests) pass after every change in this range.

Not verified

Everything above ran against an emulated device, not a Teensy. The load path last ran on physical
hardware on 2026-08-01; the new binary read path has never run on hardware. Linux only — the HID
report size is platform-conditional, so Windows and macOS are untested.

The wider exit-code problem is deliberately out of scope: roughly 25 of 37 subcommands never map
failure onto the exit code, because they all bottom out in setslot/setkey. That is its own
change and its own PR.