Resolve a Bluesky handle to its DID and fetch that account's profile, understanding when to use a DID versus a handle in subsequent API calls.

Documented steps

1. GET $PDSHOST/xrpc/com.atproto.identity.resolveHandle?handle=alice.bsky.social - this endpoint takes no auth (no Bearer token required) and returns {"did": "did:plc:..."} on success.
2. If the handle does not exist, the endpoint returns 400 with error 'HandleNotFound' - handle that case explicitly rather than assuming any 400 is a generic bad request.
3. GET https://public.api.bsky.app/xrpc/app.bsky.actor.getProfile?actor=<handle-or-did> to fetch a full profile view. The 'actor' parameter accepts EITHER a handle or a DID (format at-identifier) - no auth is required for basic profile data, though authenticated calls may return extra relevant metadata such as viewer-relationship state.
4. For fetching many profiles at once, use GET .../xrpc/app.bsky.actor.getProfiles?actor=<did1>&actor=<did2>... which accepts an array of DIDs/handles instead of looping getProfile.
5. Prefer storing and using the DID (not the handle) for any long-lived reference (e.g. a mention facet's 'did' field, a follow record's 'subject', or a database foreign key) - handles are mutable and a user can change their handle at any time, whereas the DID is a stable permanent identifier.
6. Use the handle only for user-facing display and for the initial resolveHandle lookup; once you have the DID, all further storage/reference should key off the DID.