fix(ctap): name the CTAPHID error codes, and retry a busy channel

`keyroostctl fido pin-retries` against a Solo 2 failed three times with
`device reported CTAPHID_ERROR code 0x06`, then succeeded unprompted. Two
problems, both here.

The code was printed raw. CTAPHID error codes are a fixed set of nine in
CTAP 2.1 §11.2.9.1.6, and none were defined in the crate. Each now renders as a
plain-language explanation with the spec name and hex retained, matching how
CTAP2 statuses already read. Codes outside the table keep the raw form rather
than being given an invented meaning.

`0x06` is `ERR_CHANNEL_BUSY`, which the spec says the client SHOULD retry, and
we did not. Now retried up to four attempts, 200 ms apart, under a 1500 ms wall
clock measured from the first attempt — two independent bounds, so a device
answering busy slowly terminates as surely as one answering instantly. The cap
sits below the 2 s read timeout on purpose: a busy key never makes a command
hang longer than a silent one already does. No other code is retried; the rest
indicate a real fault and retrying would only delay it.

Redaction holds across a retry: `exchange_is_sensitive` is evaluated once before
the loop, so no attempt can be classified differently from the first, and the
debug retry line carries framing metadata only.

Noted rather than changed: `send` has no zeroization today — its frame is a
plain stack local — so there was none to preserve here. That is a separate
question about a hardware-critical path.

Tested through a socketpair standing in for the hidraw node, counting the
reports the device actually receives: three sends when a busy device clears,
exactly four when it never does, exactly one for every non-busy error. The
hidapi backend on macOS and Windows is not covered by that harness, though the
retry sits above the backend split.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SQv9x6xi3CxXs2PvXohaFu

Author: framefilter