Restore portal device login for DataOps API access

Start with backend/src/docs/portal.ts:handlePortal and backend/src/router.ts, then inspect the device-auth and portal-auth tests named in the issue. Reproduce the anonymous POST failure through the combined HTTP portal/router boundary; the existing handler-only tests do not cover it. Done means the exact two POST operations work anonymously without granting identity, while the specified auth-boundary regressions and production-shaped local CLI journey pass; real operator approval remains a separate deployment check.

Restore portal device login for authenticated DataOps API access

Status: pending
Tags: bug, portal, backend, testing, P1
Depends on: none for implementation; real operator browser approval is required for live profile verification.
Blocks: reliable operator CLI/API checks, including the live invoice workflow in #232.

Problem and scope

The user requests configuring access to the DataOps API. The official CLI cannot start its legitimate device login: anonymous POST /api/auth/device against the deployed portal returns 401 before a pairing code is issued. In origin/main, backend/src/router.ts exempts device start/poll from authentication, but backend/src/docs/portal.ts:handlePortal runs first and rejects the anonymous request when browser authentication is configured. Existing isolated device-handler tests do not prove the complete deployed preprocessing path.

Repair this narrow authorization mismatch. Allow only device-start and device-token polling requests to reach their existing handlers anonymously, using exact paths and supported methods after existing /work/api normalization. Forwarding these requests must not mark them authenticated or establish a user identity. Retain normal request validation, grant expiry, attempt limits, human browser approval, token ownership and subsequent bearer verification. Reuse the existing handlers and CLI device flow rather than introducing another login or direct credential creation path.

The existing approval UI (#/device), dataops login, secure URL-keyed CLI profile, whoami, token listing/revocation and authenticated API behavior are the operator journey to verify. Production credential storage occurs only after the legitimate grant is approved and exchanged; no account secrets or raw access/device codes belong in public comments, committed fixtures, screenshots or logs. Synthetic local test credentials may be used privately in project-local scratch.

Acceptance criteria

• With browser auth configured and portal auth mode enabled, anonymous POST /api/auth/device traverses the actual portal plus router and returns the existing bounded pairing response instead of preprocessing 401. Anonymous POST /api/auth/device/token reaches the existing grant handler and returns its correct pending/denied/expired/approved outcome. Existing normalized /work/api/auth/device and /work/api/auth/device/token paths behave consistently.
• The anonymous exception is exact and limited to these two POST operations. Anonymous pending-grant lookup, approval, token management, /api/me, invoice/data APIs, sibling/prefix lookalikes and unsupported methods do not gain authenticated access. A supplied x-user-id cannot impersonate an operator. Password login remains unavailable in portal mode. Invalid bearer credentials still fail server-side validation.
• Approval requires the existing signed-in enabled operator identity, displays the expected application label/code context, and grants or denies the requested device through the existing browser flow. Starting or polling a grant cannot approve it. Missing/invalid/expired grants and disabled users do not yield a token; successful exchange retains existing single-use behavior and token expiry. No token/browser-session/device-grant TTL changes or authentication bypass flags are introduced.
• A complete local production-shaped journey uses the real HTTP portal/router with browser auth enabled and normal authorization enforcement: real CLI starts anonymously, unapproved polling stays pending, browser approval resolves the grant, CLI exchanges it, saves its existing secure profile, and a subsequent CLI whoami/read-only API call authenticates through normal bearer middleware. Tests must not prove this by setting SKIP_AUTH=true, disabling browser configuration or calling only handleCliAuthRoutes directly.
• CLI profile behavior remains URL-specific and owner-only (new credential directory 0700/file 0600), normal login output does not expose the bearer token, and denial/expiry/failure do not save a credential. Existing logout/revoke behavior remains protected. No existing peer/operator profiles are overwritten by local testing; use an isolated DATAOPS_CONFIG_DIR under .tmp/.
• Existing browser login/callback/session, portal private pages, bearer API authorization and device API regressions pass. Capture and inspect sanitized rendered approval/pending and approved/denied states for the complete changed journey, even if the UI source itself requires no changes.
• [HUMAN] After code deployment, run the official CLI device login against the configured DataOps portal, let the real operator approve it in their legitimately authenticated browser, verify the local profile and whoami, then make a read-only DataOps API check. Report this separately from local tests; no automatic or simulated production approval. Keep the issue open until this succeeds.

Required verification

Use the current consolidated TypeScript packages, not retired Python docs/work-engine commands. Tester runs:

• npm --prefix backend test
• npm --prefix backend run typecheck
• npm --prefix backend run build
• npm run test:cli
• npm run test:frontend:unit
• The new production-shaped full HTTP/portal/router + real CLI device-approval test, with browser authentication configured and SKIP_AUTH=false; name its exact reproducible command in the engineer handoff. Use synthetic enabled/disabled users and test-owned sessions against a local DynamoDB emulator or equivalent faithful store fixture, not a production identity provider.
• Playwright changed journey plus existing backend/e2e/browser-cookie-bootstrap-production-portal.spec.js and backend/e2e/auth-error-production-portal.spec.js regressions. Use an isolated test server/store and capture approval/pending/approved/denied screenshots under .tmp/screenshots/; fixture responses alone do not prove portal preprocessing. This bounded browser set is intentional for a two-endpoint authorization repair; it must exercise the full changed journey and existing authentication boundaries. Any failures or omitted commands must be documented with evidence, not called green.

Include direct and normalized path variants, wrong methods/prefix lookalikes, spoofed identity headers, unauthenticated approval, pending/denied/expired/unknown codes, disabled users, replay after exchange, valid/invalid bearer calls, CLI storage modes and failed-login no-profile behavior. Existing tests include backend/tests/device-auth.test.ts, portal-auth.test.ts, browser-auth.test.ts, api-authorization.test.ts and cli/test/cli.test.mjs; add regression coverage at the actual combined route boundary that currently fails. Validate/build SAM only if packaging or infrastructure changes are needed; no infrastructure change is expected for this scope. No content/search rebuild is needed because content and search are untouched.

Boundaries and handoff

No token TTL expansion, silent human approval, direct DynamoDB production token insertion, hardcoded credentials, broader anonymous auth prefix exemption, invoice-domain changes, alternative login product, or unrelated account migration. Runtime never creates infrastructure. This issue reuses existing grant/token storage, backups and secure CLI configuration; no new persistent family or portable schema is expected.

Implement in a clean project-local worktree based on current origin/main; shared main contains peer process-file edits and must remain untouched. PM grooming → engineer implementation → independent Tester → PM acceptance → focused commit → merge/push → On-Call. Agent-verifiable code can ship before real operator approval; use Refs #248, keep the issue open and add human only after shipped agent checks pass and the real login is the sole remaining gate.