feat(cloud): device-code workstation enrollment

[jirhiker]

Summary

Adds an RFC 8628-style device-code grant for onboarding workstations to pychronAPI without requiring email access on the lab machine.

Flow:

1. Tech clicks Start device-code enrollment in Pychron Cloud preferences.
2. Pychron POSTs /api/v1/forgejo/device-codes → server returns a polling secret (device_code) + a short admin-typed code (user_code, e.g. ABCD-EFGH) + a verification URL.
3. Pane shows the user_code and URL; tech reads them aloud to admin (or admin sees them on the workstation screen).
4. Admin signs in on any browser-capable device, enters the code, picks lab + technician email + scopes, approves.
5. Workstation's polling thread sees success → persists keypair + SSH config + OS-keyring token. Status flips to Enrolled as <lab>.

No email anywhere; works on air-gapped lab machines as long as the workstation can reach pychronAPI.

Files

• pychron/cloud/api_client.py — start_device_code + poll_device_code w/ typed errors (CloudDeviceCodePending, CloudDeviceCodeDenied, CloudDeviceCodeExpired, CloudFingerprintRejected). Both endpoints are unauthenticated (the device_code is the polling credential); no Authorization header is sent. Plaintext device_code, user_code, and api_token are stripped from .raw before the result is exposed.
• pychron/cloud/workstation_setup.py — WorkstationSetup.from_device_code classmethod orchestrates start → on_user_code callback → poll loop → persist registration + SSH config + keyring. should_cancel callback lets the UI break the loop mid-poll. Keyring failure raises KeyringWriteFailedError whose __str__ deliberately omits the token; .api_token and .lab_name attributes carry the still-in-memory plaintext for UI display.
• pychron/cloud/tasks/preferences.py — new Enroll via Device Code group. Worker thread runs from_device_code; dispatches all UI updates back to the main thread via pyface.api.GUI.invoke_later so BasePreferencesHelper's persistence listeners stay single-threaded. Live _pending_user_code + _pending_verification_url fields shown while polling. On keyring failure, _recovery_token field surfaces the token so the tech can paste it into a password manager before closing the window.
• test/cloud/test_api_client.py — TestStartDeviceCode (9) + TestPollDeviceCode (12) cover happy, status mapping, no-Authorization, secrets stripped from .raw, transport / non-JSON, empty-arg validation.
• test/cloud/test_device_code_setup.py — orchestrator tests: pending → success persists all artifacts + keyring; denied / expired propagate without persisting; should_cancel → DeviceEnrollmentCancelled; keyring-fail → KeyringWriteFailedError (token on attrs, NOT in str); empty api_base_url aborts before any I/O.

Server-side prereq

The companion server endpoints (/api/v1/forgejo/device-codes start/approve/deny/poll/list, the ForgejoDeviceCode table + alembic migration 0004, the shared mint_workstation_credential helper) live in pychronAPI and need to land first. This PR is the client-only half — without the server endpoints it'll get 404s. The server work is a separate PR in the pychronAPI repo.

Test plan

• Full test/cloud/ suite: 130 / 130 green.
• Local manual smoke: start enrollment → see code in pane → approve via test admin endpoint on staging pychronAPI → verify keypair, registration.json, ssh config, keyring all populated.
• Manual: cancel mid-poll → status shows "Enrollment cancelled".
• Manual: simulate keyring failure (revoke macOS Keychain access) → recovery token field surfaces with the plaintext for copy.

🤖 Generated with Claude Code