feat: add durable GCP management identity for post-bootstrap plan/apply

[sam-at-luther]

Summary

Reliable is implementing reliable#664 (preserve post-deploy management after bootstrap credential expiry).

For AWS, the template already appears to provision a durable project admin role that Oracle can use for post-bootstrap write operations.

For GCP, the template currently appears to provision only a read-only inspector identity:

• tf/cloud-provision/inspector.tf
• google_service_account.insideout_inspector
• viewer-style roles
• token creator binding from the deployment SA to the inspector SA

There does not appear to be an equivalent project-scoped write-management identity that Oracle can use for future terraform plan/apply/redeploy after the original uploaded service account key is no longer available.

Required behavior

For new GCP projects created from this template:

• Bootstrap may still use the caller-provided uploaded service account key.
• After bootstrap succeeds, the project must have a durable project-scoped management identity that Oracle can use for future write operations.
• Future plan/apply/redeploy must not depend on the original uploaded service account key remaining the active dependency.

Required template changes

Add a dedicated GCP management identity for steady-state write access, parallel to the existing inspector pattern but with write-capable permissions.

Requirements:

1. Provision a deterministic GCP service account for management

   • naming should be deterministic from project_id / short_project_id
   • distinct from the existing inspector SA

2. Grant this management SA the permissions needed for steady-state terraform operations

   • sufficient for the cloud-provision/custom-stack-provision lifecycle used by InsideOut
   • broad enough that existing supported GCP components can still plan/apply without falling back to the uploaded bootstrap key

3. Allow Oracle / deployment execution identity to impersonate it

   • same style of token-creator trust as the inspector flow, but for the management SA

4. Expose stable outputs / metadata so Oracle can discover and use it

   • ideally explicit outputs such as management SA email / ID
   • if there is an even simpler durable-ready signal, include that too

Rollout constraints

• This is forward-looking for new durable-ready projects.
• Do not require proactive migration of legacy projects.
• Lazy migration is fine only if it is clearly low-risk and automatic.

Acceptance criteria

• A newly deployed GCP project has a deterministic management SA intended for post-bootstrap write operations
• Oracle can discover or derive that identity from archived project state / outputs
• The management SA can be impersonated without the original uploaded service account key being passed back in from Reliable
• Existing inspector behavior remains unchanged
• Add template tests / validation coverage for the new management identity and outputs

Context

ui-core needs to add the project-scoped durable write path on the Oracle side. This template issue is the infrastructure half of that work for GCP.

Please reference luthersystems/reliable#664 in the fix.