Attach a chip passive-authentication read to a KYC check

Requires an API client bearer token.

Attaches a chip's read Document Security Object, DG1, DG2, and optionally DG15 plus an Active Authentication response, to a case (S3b). The SOD/DG2/data-groups are stored under purpose-bound custody; DG1 is parsed server-side into its MRZ text, which folds into the case's submission on a collecting case (re-running required_inputs readiness) or, on an evaluating case, enqueues a fresh chip_authenticity evaluation. The case's PINNED policy must list chip_authenticity in required_signals, checked BEFORE anything else — a case on a programme that never enabled it 409s (chip_not_accepted). When the body carries `aa`, the named challenge (minted via POST .../chip-challenge) is consumed exactly once; an expired, already-consumed, or foreign challenge 400s before anything is stored. Unlike GET .../chip-keys (reveal-only while the case is pending — collecting or evaluating — and awaiting a chip read, RIGID-587 follow-up), this endpoint also accepts on a referred case too — an API caller holds the MRZ itself and does not need this service to hand it back first. Requires an Idempotency-Key header. Callable by `user` or `admin` callers, which includes API clients (OAuth2 client-credentials).