sec(archera): verify archeraError masks the API key AFTER sanitizing (zero-width-split key can be reassembled) #56

Found by the cli #2166 gate (finding F1, comment 6123800222 on LeanerCloud/cloud-commitments-cli#2166); the same pattern may exist in mcp tools/archera_comparison.go archeraError (merged in #55).

Problem to verify

archeraError formats HTTP errors as fixed text (vendor message dropped), but for any other error it does key-mask, then strips control/format/line-separator characters, then caps at 256 bytes. If the mask runs BEFORE the strip, a vendor (or decode error) that echoes the API key with zero-width/bidi/control characters spliced into it defeats the exact-match mask, and the strip then reassembles the plain key in the output. The cli gate reproduced exactly this in the cli equivalent (archeraSafeError): HTTP 403: bad key test-key-SYNTHETIC-0000. Also: a key echoed back as a decode-error enum value must be masked.

To do

1. Check mcp archeraError order of operations on main with a synthetic key echoed (a) split by U+200B / U+202E / a control char, (b) twice, (c) straddling the 256-byte cap, (d) as the value in a decode error. Show real output.
2. Fix: sanitize first, then mask the trimmed key (case-sensitive substring), then cap. Tests for each case, failing before.
3. Related: go#286 (strip Cf/Zl/Zp in pkg cleanMessage before redact) and go#337/#336; consumers can drop stopgaps after pin bumps.