Records an end-user's decision on a pending CIBA authentication request and, for a ping-mode request, delivers the §10.2 notification - so a host's authentication-device UI does not hand-roll the approve→notify sequence.

After the end-user authenticates (or refuses) on their authentication device, the host calls approve/3 or deny/2 with the auth_req_id. Each drives the atomic Attesto.CIBA.approve/4 / deny/3 core transition, then - when the request was registered for ping delivery - POSTs the notification to the client's registered backchannel_client_notification_endpoint (Authorization: Bearer <client_notification_token>, body {"auth_req_id": ...}) through the configured AttestoPhoenix.CIBAPing deliverer. The §10.2 notification fires on approval AND denial; a poll-mode request sends none. Delivery is async and best-effort: the tokens are already available at the token endpoint, so a client that misses the ping falls back to polling.

The notification endpoint is resolved from the client's registration (AttestoPhoenix.Config.client_ciba_registration/2, :client_notification_endpoint), looked up by the client_id the core decision returns; a ping request whose client has no resolvable endpoint simply sends nothing (logged).