feat(MM-94): POST /v1/handles — handle creation with DnsProvider trait and session auth" · pull #29

Summary#

POST /v1/handles: New endpoint for initial handle creation on promoted accounts. Validates handle format (<name>.<available_domain>), enforces uniqueness (409), optionally calls a DnsProvider if configured (dns_status: "propagating"), and inserts into the handles table.
V009 migration: Rebuilds sessions table with nullable device_id (devices are deleted at DID promotion) and adds token_hash UNIQUE column for Bearer token authentication.
Session auth from POST /v1/dids: MM-90's promotion transaction now generates a session token and returns it in the response (session_token field), replacing the shortcut handle insertion. Clients use this token to authenticate the subsequent POST /v1/handles call.
DnsProvider trait (dns.rs): Object-safe async abstraction (Pin<Box<dyn Future>>). AppState carries Option<Arc<dyn DnsProvider>>, always None for v0.1 — MM-142 wires in real provider implementations.
New error codes: HandleAlreadyExists (409), DnsError (502).

Handle insertion removed from MM-90 (it was a shortcut bypassing format validation and DNS). POST /v1/handles is now the canonical path.
DnsProvider trait is v0.1-ready (no implementations yet); MM-142 adds Cloudflare/Route53 without changing the handler.
Session token uses the same SHA-256 hex storage pattern as pending_sessions.

cargo test — 201 tests pass, 0 failures
POST /v1/dids response now includes session_token (non-empty base64url string)
POST /v1/handles with valid session token + valid handle → 200, dns_status: "not_configured", handle row in DB
POST /v1/handles duplicate handle → 409 HANDLE_ALREADY_EXISTS
POST /v1/handles invalid format (no dot, wrong domain, leading hyphen) → 400 INVALID_HANDLE
POST /v1/handles missing/expired session token → 401 UNAUTHORIZED
POST /v1/handles account_id mismatch → 401 UNAUTHORIZED