docs(auth,devices): Beam WO5 batch 3 — 15 endpoints backfilled, registry pinned

Beam backfilled auth core (login/register/refresh/logout/profile) and devices
core (list/update/delete/shelf CRUD/sidecar/register flow) with frontmatter,
provenance, and labeled examples. All claimed shapes verified against
handlers: AuthResponse {access_token, refresh_token omitempty, token_type,
expires_in, user}, update device {device_updated, device}, shelf wrappers,
DeviceAuthStatusResponse.

Claude registry verification: 15 entries pinned by type (LoginRequest,
RegisterRequest, AuthResponse, RefreshTokenRequest/Response, UserProfile,
DeviceListResponse, DeviceUpdateRequest, AddToShelfRequest, SidecarConfig,
DeviceRegistrationRequest/Response, DeviceAuthStatusRequest/Response).
Removed revoke_device.md — name-only duplicate of delete_device.md (same
DELETE /api/devices/:id route; was the last audit-orphan doc).

Gate catches this round (subtle Go serialization facts, now pinned in docs):
- uuid.UUID arrays never serialize as omitted: register/status response
  ALWAYS carries device_id (all-zeros while pending) despite omitempty
- update device request binds device_name, not name
- register response includes device_id alongside registration_id
- list devices response is a {devices, total} wrapper

docs/developer/api/devices/get_devices.md

@@ -1,3 +1,11 @@
+---
+method: POST
+path: /api/devices/register/status
+auth: none
+area: devices
+---
+<!-- source: internal/handlers/devices.go:178 DeviceHandler.CheckRegistrationStatus -->
+
 # Get Device / Check Registration Status
 
 Check device registration status or get device details.
@@ -14,7 +22,7 @@ Check device registration status or get device details.
 
 ### Example Request (Status Check)
 
-```json
+```json example-request
 {
   "registration_id": "registration-uuid"
 }
@@ -22,22 +30,18 @@ Check device registration status or get device details.
 
 ## Response (200 OK)
 
-```json
+```json example-response
 {
-  "status": "pending|approved",
-  "message": "awaiting user approval",
-  "expires_in": 123,
-  "auth_token": "device-bearer-token...",
-  "device_id": "uuid",
-  "sync_endpoints": {
-    "progress": "https://bookhoard.com/api/sync/progress",
-    "metadata": "https://bookhoard.com/api/sync/metadata",
-    "annotations": "https://bookhoard.com/api/sync/annotations"
-  }
+  "status": "pending",
+  "device_id": "00000000-0000-0000-0000-000000000000"
 }
 ```
 
-`status` is `pending` or `approved`. While pending, the response includes `message` and `expires_in` (seconds remaining). Once approved, the response includes `auth_token`, `device_id`, and `sync_endpoints`; `auth_token` fields are empty when pending.
+`device_id` is always present (a uuid.UUID array never serializes as omitted —
+it reads as all-zeros while pending). `status` is `pending` or `approved`.
+While pending, the response includes `message` and `expires_in` (seconds
+remaining). Once approved, the response includes `auth_token`, `device_id`,
+and `sync_endpoints`; `auth_token` fields are empty when pending.
 
 **The approved response is single-use**: the registration is deleted from the pending map once returned, so store the `auth_token` immediately. A repeat status check for the same `registration_id` returns 404.