Function atproto_did 

async fn atproto_did(
    __arg0: State<AppState>,
    uri: Uri,
    headers: HeaderMap,
) -> Response

GET /.well-known/atproto-did

The other direction from did.json: that one says what a DID resolves to, this says which DID answers to a name. A deployment that issues its agents handles publishes a second hostname per account, and this is what makes it a handle rather than a decoration — the plain-text DID, which is what the atproto handle resolution rule asks for.

It answers exactly when the account’s DID document claims the host as its handle, because the registry derives both from one function. That is atproto’s bidirectional rule holding by construction rather than by agreement: a resolver that follows this DID to its document and looks for the handle in alsoKnownAs finds it, for every account, always. A name nobody holds is a 404, which is the whole of what a resolver reads here.