fix: check GCP registry consumers without decoding whole deployment records

[alongubkin]

Summary

When a GCP deployment is deleted, the manager removes the project's shared Cloud Run grant on the artifact registry only if no other deployment runs in that project. It checked this by listing every GCP deployment as a full DeploymentRecord. That decode includes stack and runtime state. If one record carries a resource config that the current types reject (for example, a prepared Worker from an older release that still has ingress), the whole list fails. Then every GCP revoke on that manager fails, and deleted deployments keep read access to the registry. The failure happens after the deletion is committed, so nothing retries it.

• DeploymentStore::has_other_gcp_project_deployment(caller, project_number, excluding_deployment_id) answers that one question. The default implementation reads list_deployments, so the SQLite store behaves the same as before. A store that can read a deployment's id, status and environment without decoding the rest of the record should override it.
• revoke_registry_access uses it. If the check cannot be answered, it still fails closed: the grant stays and the revoke returns REGISTRY_ACCESS_CLEANUP_FAILED.

Testing

• the_last_deployment_in_a_gcp_project_revokes_its_shared_grant, a_shared_grant_stays_while_another_deployment_uses_the_project, an_unanswered_consumer_check_keeps_the_grant_and_fails_the_revoke: these run revoke_registry_access against a recording registry and a mock store. The mock store fails the test if the revoke calls list_deployments.
• only_another_deployment_in_the_same_project_keeps_the_shared_grant: tests the default implementation against a real SQLite store (self, another project, a sibling, then the sibling removed).
• cargo test -p alien-manager --lib: 316 passed (Linux sandbox, CARGO_INCREMENTAL=0, debuginfo off).
• I also checked a store override that reads only placement fields against a mock HTTP API. With a record that has a legacy Worker config: the full-record list fails, and the override still gives the right answer for both the same project and another project.

🤖 Generated with Claude Code

[alongubkin]

@greptileai review

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Refactors GCP registry access revocation logic.

The PR appears safe to merge; the missing deleted-sibling coverage is restored.

What we checked:

• Deleted siblings are covered: create_with_state stores the supplied status. The query does not filter out deleted rows, so the test checks that the consumer method excludes them.

Summary

The PR lets stores answer the shared GCP registry-grant question through has_other_gcp_project_deployment. Its default implementation preserves the existing behavior; stores can override it to avoid decoding whole records.

• Registry cleanup keeps the shared grant when another deployment uses the project or the check fails.
• The latest change restores coverage for a stored deleted sibling while keeping the hard-delete case.
• No new actionable issues were found.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[GCP registry cleanup] --> B[Ask store about other project deployments]
  B -->|Another deployment exists| C[Keep shared grant]
  B -->|Check fails| D[Keep grant and return cleanup error]
  B -->|No other deployment| E[Remove shared grant]

Loading

_{Reviews (3) · Last reviewed commit: "style: rustfmt the GCP consumer test" · Reviewed by Greptile}

[alongubkin]

@greptileai review

[alongubkin]

@greptileai review