Function approve_authorization 

pub(crate) async fn approve_authorization(
    __arg0: State<AppState>,
    headers: HeaderMap,
    __arg2: XrpcBody,
) -> Response

POST /xrpc/bot.did.approveAuthorization

The one way an authorization is approved. Credential::AccountSelf: the agent presents its own token, and the decision it approves must be the one addressed to that account — plan/oauth.md’s “the account is checked server-side, not by the daemon”, enforced by the credential rather than by a DID in the body a caller could write anything into.

Answers with the client’s redirect, built here from the pending consent’s own redirect_uri and state and the pushed request’s response_mode — which is the whole of what an approving caller is not allowed to see — and this server’s issuer. A loopback redirect carrying its code in the query is the caller’s to deliver, because this server cannot reach the host the client listens on. A browser carries any other (crate::oauth::authorize::browser_carries): the approval holds it for GET /oauth/authorize to hand to a browser signed in as the account.

Answers with the scope the decision record granted, which is what the code carries: a token is issued at that set as the ceiling grants it at exchange, and judged the same way at every use after.

The approval is remembered for the account and the client’s crate::oauth::client_metadata::ClientKey, at this grant; see crate::oauth::decision::DecisionStore::remember.

Nothing is evaluated here. The record PAR wrote is read, and a policy loaded since that push does not reach back into it — see crate::oauth::par.