Run the card-terminal round-trip self-test

Commands the resolved payment provider through two probes, in this order: authorize -> capture, then authorize -> void. It exists so a human on the till’s peripherals screen can prove the terminal is wired; an agent should reach for it ONLY on an explicit operator request to test the terminal, never to ‘check’ anything. Use getPaymentTerminalConfig for that. WHY avoid: (1) it talks to the provider with the deployment’s REAL credentials, so with a live Adyen POI it engages the physical reader mid-shift and asks a person to present a card; (2) the capture probe SETTLES its authorization and the round-trip never reverses it, so a green run leaves a captured payment of amountCents behind — only the second, void probe is released; (3) nothing in this route asserts test mode. The ‘sandbox’ guarantee is entirely environmental (an sk_test_ Stripe key, the Adyen TEST host); the code does not check it. NOT IDEMPOTENT: every call issues two FRESH authorizations. There is no read-back endpoint for the result, so a call that times out must NOT be retried blindly — the authorizations may already have been taken. Ask the operator to inspect the provider dashboard instead. Body: send at least {}; amountCents (integer minor units, default 100 = 1.00, max 1 000 000) and currency (3-letter ISO 4217, default EUR) override the probe amount — keep it small, it is money. Unknown keys are rejected. Always inspect ok (true only when all four steps passed); steps[].detail is free-form engineering text, never a machine field. The enabled toggle does NOT gate this route: a terminal an operator switched off still runs the round-trip. ERROR-VOCABULARY TRAP (solya-pos#955): the 422 this route returns when the selected provider has no credentials carries error.code: "PSP_NOT_CONFIGURED", which is NOT a member of the kernel ResultCode enum the shared ErrorResponse component documents. Match that string literally rather than expecting a documented code.