Headless auth: 'whoami' ignores HARBOR_TOKEN, and 'crypto setup' can't run under it at all

[cloudmanic]

Two related defects in the HARBOR_TOKEN (headless / CI) auth path, found while end-to-end testing #86 against a real server.

1. harbor whoami ignores HARBOR_TOKEN and claims you are logged out

runWhoami (cmd/auth.go:684) reads config.Load() directly instead of going through the credential resolution at cmd/root.go:310 that honours HARBOR_TOKEN. So with a perfectly good token in the environment:

$ HARBOR_TOKEN=<redacted> HARBOR_API_URL=https://<host>/api/v1 harbor whoami
Error: not logged in — run 'harbor login' first

$ HARBOR_TOKEN=<redacted> HARBOR_API_URL=https://<host>/api/v1 harbor profile get
(succeeds — returns the authenticated user)

whoami is the natural command to run first when scripting against the CLI, so this reads as "my token is broken" when nothing is wrong. Every other command works.

Fix: resolve credentials the same way the rest of the tree does, and report the identity the token actually belongs to.

2. harbor crypto setup cannot run under HARBOR_TOKEN at all

$ HARBOR_TOKEN=<redacted> HARBOR_PASSPHRASE=<redacted> harbor crypto setup
Error: The request was invalid.
  code: validation_failed
  • scope_id: scope_id and device_id are required

HARBOR_TOKEN synthesizes a credential set with an empty DeviceID (cmd/root.go:312), but crypto setup writes the keystore through sync/push (cmd/crypto.go:130), which requires one. The result is that encryption cannot be set up headlessly at all — the documented escape hatch for CI and scripting works for every other command but this one.

Workaround used during testing: hand-write a credentials.json containing a device_id, i.e. reproduce by hand what harbor login writes.

Fix: synthesize a stable device_id for the HARBOR_TOKEN path (the same shape harbor login generates, e.g. cli-<something>), so token-only sessions can push sync records.

Acceptance criteria

• harbor whoami under HARBOR_TOKEN reports the authenticated identity instead of "not logged in"
• harbor crypto setup succeeds under HARBOR_TOKEN with no pre-existing credentials.json
• harbor crypto status afterwards reports the keystore present and unlockable
• Tests cover both, with no network and no config (mock server + temp HOME)

Context

Found while verifying #86 (PR #87). Neither affects that fix — flagged separately so they do not evaporate with the PR description.