feat: CLI mints scoped tokens for release; per-project scope on OCI push (ALIEN-139)

[ItamarZand88]

Summary

Two OSS-side changes that together let alien release work against a manager when the caller is authenticated with an OAuth bearer, plus follow-up CLI hardening:

1. CLI exchanges the user OAuth JWT for a short-lived, project-and-manager-scoped token before talking to any manager endpoint, and uses that token for the artifact-registry setup + OCI push.
2. alien-manager gains a per-project scopes field on Subject and enforces it on the OCI push path — a token whose scopes don't cover the target project's ID is rejected at /v2/.../blobs/uploads/.
3. CLI follow-ups (a) surface the manager's response body in error messages so the user sees the actual reason (auth failure, scope mismatch, etc.) instead of just an HTTP status, and (b) unblock alien commands invoke in platform mode (previously errored out before reaching the manager).

OSS standalone behaviour is preserved bit-for-bit: validators that don't populate scopes leave it empty, and the new scope check no-ops on empty scopes — so existing single-tenant deployments still work without any token-format changes.

Commits

feat(manager): per-project scope on Subject, enforced on OCI push	Subject.scopes: Vec<String> field; require_push_auth suffix-matches /<project_id> against the JWT's scope list when non-empty. Also fixes LocalArtifactRegistry::upstream_repository_prefix() which was returning a hardcoded "artifacts/default" instead of the binding name — that was masked before because no per-project authz extracted the real project_id from the routing table.
feat(cli): exchange OAuth JWT for manager-scoped token on release	mint_registry_push_token + get_or_mint_registry_push_token in crates/alien-cli/src/auth.rs. Cached in keyring under MANAGER_TOKEN_USER (separate slot from the OAuth tokens so logout cleans both). execution_context.rs mints once at the top of the platform-mode release flow and reuses the token for /v1/artifact-registry/* repo setup + /v2/... OCI push.
test: cover the per-project scope check on the OCI push path	Extracts scopes_cover_project from require_push_auth so the security-critical predicate is unit-testable without standing up a 17-field AppState. 5 tests cover empty/matching/non-matching/multi-scope/leading-slash-substring-guard cases, plus 7 tests for token_matches_target covering match, manager mismatch, project mismatch, missing claim, malformed JWT, etc.
refactor(cli): match codebase conventions on URL encoding and cache writes	(1) urlencoding::encode(manager_id) in the mint URL — matches the established pattern in execution_context.rs::resolve_url and the gcp/aws clients. (2) store_manager_token is now best-effort (warn! on keyring write failure instead of aborting the release) — matches the worked example in alien/CLAUDE.md under "When warn! Is Appropriate".
fix(cli): surface manager response body and unblock commands invoke in platform mode ✨ NEW	(1) create_or_get_artifact_repo reads each response's body once via .text().unwrap_or_default(); surfaces the manager's structured error in the final Failed to create artifact repository message instead of dropping it. (2) commands_task branches: in platform mode, resolves the project + manager to get an authenticated client + bearer (previously server_sdk_client()'s platform arm errored out, blocking step 5 of onboarding); standalone/dev keep the existing path.

Verification

• cargo test -p alien-manager — 108 tests passing across 6 binaries (was 103 before the scope-check predicate tests landed)
• cargo test -p alien-manager --test registry_proxy_test — 7 tests including push-auth, all green
• cargo test -p alien-cli --features platform --lib oauth_flow::tests — 7 tests for token_matches_target, all green
• cargo build -p alien-cli --features platform — clean
• Live end-to-end: alien release --experimental from a worker-template project succeeds and produces a release ID

Backward compatibility

• OSS standalone managers run unchanged. Validators that don't set Subject.scopes leave it empty, and the new scope check is gated on !subject.scopes.is_empty().
• The CLI's token-mint flow only activates in #[cfg(feature = "platform")] ExecutionMode::Platform. Standalone CLI use (ALIEN_MANAGER_URL=...) is unchanged.
• The platform-mode branch in commands_task is gated under #[cfg(feature = "platform")]; non-platform builds still go through server_sdk_client() directly.

Out of scope (separate tickets)

• Subject.scopes: Vec<String> is loosely typed — format "<workspace_id>/<project_id>" enforced only by doc comment. A typed permits_project_push(project_id) helper on Subject would kill the open-coded ends_with matching at call sites.
• The platform-mode alien commands invoke flow currently re-uses the registry-push token. A separate, more-specific audience would match the operation's intent better — track in a follow-up using the documentation skill on the platform side.

Test plan

• Reviewer runs cargo test -p alien-manager and confirms 108/108.
• Reviewer runs cargo build -p alien-cli --features platform and confirms clean.
• Reviewer confirms Subject.scopes default-empty behaviour preserves OSS standalone: grep for Subject { literals in OSS validators shows scopes: Vec::new() everywhere.

[greptile-apps]

Greptile Summary

This PR wires up scoped-token authentication for alien release in platform mode: the CLI now exchanges its OAuth JWT for a short-lived, manager-and-project-scoped JWT before talking to any manager endpoint, and the manager enforces that JWT's scopes list against the target project on the OCI push path.

• CLI (auth.rs, execution_context.rs): adds mint_registry_push_token / get_or_mint_registry_push_token with keyring caching and expiry-aware cache reuse; create_or_get_artifact_repo now surfaces manager response bodies in error messages; commands_task gains a platform-mode branch to resolve the manager before constructing the SDK client.
• Manager (registry_proxy.rs, subject.rs): adds Subject.scopes: Vec<String> and a scopes_cover_project helper; require_push_auth rejects pushes whose token scope doesn't cover the target project; OSS validators set scopes: Vec::new() and the check no-ops on empty scopes, preserving backward compatibility.
• Tests: 5 unit tests for scopes_cover_project and 7 for token_matches_target cover all boundary cases including substring-suffix collisions and malformed JWTs.

Confidence Score: 4/5

Safe to merge for AWS-based platform deployments; the hardcoded "aws" platform string in the new commands invoke platform-mode path should be verified against non-AWS deployments before considering those use cases fully supported.

The core token-exchange flow, scope enforcement on the OCI push path, and OSS backward compatibility are all correctly implemented and well-tested. The only open question is whether resolve_manager(..., "aws") in commands_task behaves correctly for GCP or other projects — the same pattern exists in deployments.rs so it may be intentional, but it limits the commands invoke path to AWS in the same way deployments ls is already limited.

crates/alien-cli/src/commands/commands.rs — the hardcoded "aws" platform argument on the new resolve_manager call.

Important Files Changed

Filename	Overview
crates/alien-cli/src/auth.rs	Adds mint_registry_push_token, get_or_mint_registry_push_token, token_matches_target, store_manager_token, load_manager_token, plus a MANAGER_TOKEN_USER keyring slot; token caching logic and expiry handling are correct; comprehensive unit tests for matching/mismatch/malformed cases.
crates/alien-cli/src/commands/commands.rs	Unblocks alien commands invoke in platform mode by resolving the manager before the SDK client is created; resolve_manager is called with a hardcoded "aws" platform string which may not hold for non-AWS projects.
crates/alien-cli/src/execution_context.rs	Mints the manager-scoped JWT before artifact-repo setup and OCI push; adds manager_id to ResolveResponse; error messages now surface manager response bodies; flow is clean.
crates/alien-manager/src/auth/subject.rs	Adds scopes: Vec<String> field with correct Default semantics; all existing OSS validators explicitly set scopes: Vec::new() preserving backward compatibility.
crates/alien-manager/src/routes/registry_proxy.rs	Adds scopes_cover_project helper and integrates it into require_push_auth; empty-scopes passthrough preserves OSS behavior; leading-slash guard prevents substring collisions; 5 unit tests cover all boundary cases.
crates/alien-manager/tests/registry_proxy_test.rs	Updates test_subject() with the new scopes field; integration tests still use Vec::new() (OSS path); the security-critical scoped-rejection path is covered by scopes_cover_project unit tests in the production module.

Sequence Diagram

sequenceDiagram
    participant CLI
    participant PlatformAPI as Platform API
    participant Keyring
    participant Manager

    CLI->>PlatformAPI: "GET /v1/resolve?platform=X&project=Y&workspace=Z"
    PlatformAPI-->>CLI: manager_url, manager_id, project_id

    CLI->>Keyring: load cached manager token
    Keyring-->>CLI: cached token or none

    alt cached token is valid and matches manager+project
        CLI->>CLI: reuse cached token
    else expired or wrong target
        CLI->>PlatformAPI: POST /v1/managers/ID/token (purpose: registry-push, project)
        PlatformAPI-->>CLI: scoped manager token
        CLI->>Keyring: store token (best-effort)
    end

    CLI->>Manager: GET /v1/artifact-registry [Bearer scoped token]
    Manager-->>CLI: repo info

    CLI->>Manager: POST /v2/.../blobs/uploads [Bearer scoped token]
    Manager->>Manager: role check via can_push_image
    Manager->>Manager: scope check via scopes_cover_project
    Manager-->>CLI: OCI push accepted

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
crates/alien-cli/src/commands/commands.rs:84-85
**Hardcoded `"aws"` platform on manager resolution**

`resolve_manager` is called with a hardcoded `"aws"` value, which is used verbatim in the `/v1/resolve?platform=aws&...` query. For a project hosted on GCP (or any other non-AWS provider), the platform API would receive an incorrect hint, potentially routing to the wrong manager or returning an error. The `release` flow avoids this by reading the platform from the project's `platforms` config (`&platforms[0]`). Note that `deployments.rs:280` has the same hardcode, so this is a pre-existing pattern — but it is worth confirming whether the platform API's `/v1/resolve` endpoint silently ignores the `platform` query param for commands/deployments operations, or whether this would fail for GCP projects.

_{Reviews (5): Last reviewed commit: "fix(cli): fail loud on success-status re..." | Re-trigger Greptile}

[ItamarZand88]

Superseded by #49 — same code, clean history (no force-push trail, no orphan commits with OSS-boundary leaks that earlier rounds introduced).