relayfile login mints delegated credentials with insufficient scope (401 on new-workspace bootstrap)

[khaliqgant]

Bug

A completely fresh `agent-relay cloud login` (browser flow, real re-auth, not a stale cached session) only grants scopes:

```
Scopes: auth:workspace:follow-user, cli:auth
```

`relayfile login` (with no flags — the normal browser-based path, not the broken `--no-open` path from #378) then fails when bootstrapping delegated relayfile credentials for a workspace it hasn't seen before:

```
Already logged in to https://agentrelay.com/cloud
error: bootstrap delegated relayfile credentials: mint delegated relayfile credentials: http 401 unauthorized: Unauthorized
```

Reproduction (exact steps)

1. `agent-relay cloud logout`
2. `agent-relay cloud login` — completes successfully, browser flow works, `agent-relay cloud whoami` confirms a valid session with the scopes above
3. `relayfile login` (targeting the hosted service, no `--server`/`--token` override) — fails with the 401 above

Reproduced twice: once against a session that had been sitting for a while, and once immediately after a completely fresh `cloud login`. Same scopes, same 401 both times — this rules out a simple stale-token explanation.

Workaround attempted, also blocked

Reusing an existing workspace that already has working delegated credentials (one that was bootstrapped previously, e.g. by another tool) avoids the mint call and works fine — `relayfile` commands against that workspace succeed. But that's not usable as a general workaround: a workspace already mirrored locally by another process cannot be mounted a second time without `--rehome`, which would break the existing mirror.

Impact

Any genuinely headless/scripted first-time `relayfile login` against the hosted service — a fresh machine, a fresh workspace, a fresh CI/agent context — cannot bootstrap delegated relayfile credentials at all. The only workaround right now is self-hosting a relayfile server, which sidesteps this cloud auth path entirely.

Where to look

• `cmd/relayfile-cli/main.go` around the `login`/bootstrap-delegated-credentials flow (search `bootstrap delegated relayfile credentials`, `mint delegated relayfile credentials`) — does the delegated-mint call request/expect a scope that `agent-relay cloud login`'s default grant doesn't include?
• Whether `agent-relay cloud login` needs an explicit scope request (e.g. a flag) for relayfile delegation, and if so, whether `relayfile login`'s wrapper call is passing it.
• Related to login --no-open forwards a flag agent-relay doesn't have — headless login is impossible #378 in that both are in the headless/first-time-login path, but this is a distinct root cause (scope grant, not an unsupported `--no-open` flag) — confirmed by reproducing this independently of `--no-open`.

[khaliqgant]

Investigated. This is not a relayfile bug — the fix belongs in the cloud repo, not here. No relayfile source was changed.

Findings:

• relayfile login correctly forwards the Cloud bearer token to /relayfile/delegated-token.
• Agent Relay v11.4.0 exposes no login scope parameter to request additional scopes.
• Cloud's own login hardcodes the scope grant to cli:auth + auth:workspace:follow-user.
• Cloud's delegated-token route explicitly accepts cli:auth — so the original "insufficient scope" hypothesis in this issue is wrong. A genuinely missing scope would return 403, not 401.
• The 401 we're actually seeing only happens when Cloud's resolveRequestAuth fails to resolve a bearer token — even though agent-relay cloud whoami recognizes that exact token as valid. That's a token-store / database-binding / routing consistency issue on Cloud's side, not a relayfile-side scope problem.
• Cloud's own delegated-token route tests mock resolveRequestAuth, which is exactly why this integration failure has never been caught by that repo's test suite.

Verified (relayfile-side, confirming no regression / no fix needed here):

go test ./cmd/relayfile-cli -run '^(TestLoginDelegatesToAgentRelay|TestWorkspaceJoinStoresDelegatedRelayfileCredentials)$' -count=1
ok  github.com/agentworkforce/relayfile/cmd/relayfile-cli

Leaving this open since it's a real, reproducible bug a relayfile user hits — but retitling scope in my head to "Cloud's resolveRequestAuth rejects a bearer token that cloud whoami accepts" and the actual fix needs to happen in the cloud repo (likely wherever resolveRequestAuth and the delegated-token route live). Someone should file the corresponding issue there and link back here.