fix: reconcile hosted setup updates through Platform

[alongubkin]

Summary

• route hosted compute changes through Platform across active and retryable setup lifecycles
• authorize same-release setup reconciliation with the owning Platform operation ID
• retain authorization through setup/provisioning and consume it only after success

Validation

• deployment engine direct-setup lifecycle tests
• generated CLI hosted lifecycle routing test

[alongubkin]

Superseded by a convention-compliant branch for ALIEN-612.

[greptile-apps]

Greptile Summary

The PR routes hosted compute changes through Platform during active and retryable deployment lifecycles and adds persisted authorization for same-release direct-setup reconciliation.

• Adds a serialized direct-setup authorization carrying Platform operation and release identities.
• Redirects authorized same-release updates through initial setup and provisioning.
• Retains authorization across retryable failures and consumes it after successful provisioning.
• Expands hosted CLI routing beyond the Running state and adds lifecycle coverage.

Confidence Score: 3/5

The PR should not merge until direct-setup reconciliation is fenced to the Platform operation that currently owns it.

The new authorization carries an operation identity specifically for stale-write fencing, but the deployment engine ignores that identity and accepts any retained authorization matching the same release.

Files Needing Attention: crates/alien-deployment/src/updating.rs and crates/alien-core/src/deployment/state.rs

Security Review

The authorization check does not enforce the operation identity documented as fencing stale Platform writes, allowing a retained same-release authorization to be honored after ownership changes.

Important Files Changed

Filename	Overview
crates/alien-core/src/deployment/state.rs	Adds the persisted direct-setup authorization contract, including an operation ID whose documented fencing purpose is not enforced.
crates/alien-deploy-cli/src/commands/up.rs	Expands Platform-hosted compute routing to active and retryable setup/update states and tests the status classification.
crates/alien-deployment/src/updating.rs	Introduces same-release direct-setup reconciliation but authorizes it without checking the owning Platform operation ID.
crates/alien-deployment/src/pending.rs	Prepares direct-setup reconciliation by replacing the prepared stack and clearing stale pending update state.
crates/alien-deployment/src/provisioning.rs	Consumes direct-setup authorization only after provisioning reaches Running.
crates/alien-deployment/src/lib.rs	Clears setup authorizations when a newer target release starts normal update reconciliation.
crates/alien-deployment/tests/test_platform.rs	Covers successful same-release direct-setup reconciliation but not stale operation ownership.

Sequence Diagram

sequenceDiagram
    participant CLI as alien-deploy
    participant Platform
    participant Engine as Deployment engine
    participant Setup as Setup provisioning
    CLI->>Platform: PATCH hosted compute settings
    Platform->>Engine: Persist authorization and UpdatePending
    Engine->>Engine: Check direct-setup authority and release IDs
    Note over Engine: operation_id is not checked
    Engine->>Setup: Reconcile setup-owned resources
    Setup-->>Engine: InitialSetup / Provisioning result
    Engine->>Engine: Retain authority on failure
    Engine->>Engine: Clear authority after Running

Loading

Prompt To Fix All With AI

### Issue 1
crates/alien-deployment/src/updating.rs:32-37
**Operation fence is ignored**

If a retained authorization belongs to an earlier Platform operation for the same release, `direct_setup_update_is_authorized` accepts it without checking `operation_id`, causing stale administrator-credentialed setup reconciliation after operation ownership changes.

**How this was verified:** The authorization predicate checks setup authority and release IDs only, while `operation_id` is explicitly documented as the stale-write fence.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix: reconcile hosted setup updates thro..." | Re-trigger Greptile}

[greptile-apps]

Operation fence is ignored

If a retained authorization belongs to an earlier Platform operation for the same release, direct_setup_update_is_authorized accepts it without checking operation_id, causing stale administrator-credentialed setup reconciliation after operation ownership changes.

How this was verified: The authorization predicate checks setup authority and release IDs only, while operation_id is explicitly documented as the stale-write fence.

Knowledge Base Used: CLI and deployment workflows

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/alien-deployment/src/updating.rs
Line: 32-37

Comment:
**Operation fence is ignored**

If a retained authorization belongs to an earlier Platform operation for the same release, `direct_setup_update_is_authorized` accepts it without checking `operation_id`, causing stale administrator-credentialed setup reconciliation after operation ownership changes.

**How this was verified:** The authorization predicate checks setup authority and release IDs only, while `operation_id` is explicitly documented as the stale-write fence.

**Knowledge Base Used:** [CLI and deployment workflows](https://app.greptile.com/alien/-/custom-context/knowledge-base/alienplatform/alien/-/docs/cli-and-deployment.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.