Step-up Consume

The original mTLS caller and token sid consume a verified challenge with the original request_ref and digest. The database atomically records consumption and expires_at = issued_at + 5 seconds; reject if fewer than five challenge seconds remain. Repeating the same request returns the same permit_id and original expiry, even after permit expiry; replay never extends authority. Different challenge/digest/sid/caller is rejected. Products check expiry and target/action and deduplicate permit_id inside their own business transaction. PostgreSQL does not make the product transaction atomic with Control. The permit is a consumed-challenge projection and an idempotency result, not a new table or identity token.

POST /api/sessions/step-up/consume