feat(relay): implement POST /v1/accounts (MM-83) #23

Summary#

Adds POST /v1/accounts — operator-authenticated endpoint that provisions a pending account slot with a 24h claim code, before any DID is assigned
V005 migration introduces pending_accounts staging table; email and handle uniqueness is enforced across both pending and active (accounts) tables
Three new ErrorCode variants: AccountExists (409), HandleTaken (409), InvalidHandle (400)

V005__pending_accounts.sql — pending_accounts(id, email, handle, tier, claim_code FK→claim_codes, created_at) with unique indices on email and handle
routes/create_account.rs — handler + 26 tests covering happy path, DB persistence, duplicate email/handle (both tables), handle format validation, tier validation, missing fields, auth, and DB error path
bruno/create_account.bru — Bruno collection entry
uuid v1 workspace dep for UUIDv4 account_id generation

pending_accounts is a staging area: no DID is assigned yet. A future wave handler will promote a row to accounts after device binding.
Handle validation is intentionally minimal (non-empty, ASCII, no whitespace, ≤253 chars) — ATProto handle/domain policy is deferred to a later wave to avoid incorrect rejections.
Both the claim_codes insert and the pending_accounts insert happen in one transaction, preventing orphaned codes.

cargo test — 112 tests, all passing
cargo clippy --workspace -- -D warnings — clean
Manually test via Bruno: POST /v1/accounts with valid payload returns 201 with accountId, claimCode, did: null, status: "pending"
Verify duplicate email returns 409
Verify invalid handle (e.g. empty string) returns 400