[Bug] gemini-stage-1: shared-VPC network resolution relies on try() fallbacks against stage-0 outputs — misleading failure when outputs are absent or misshaped

[JohnHales]

Bug Description

The google_compute_network.gemini_enterprise_vpc data source in gemini-stage-1/load_balancer.tf (lines 41–49) resolves both the project and the network name through try(data.terraform_remote_state.stage_0.outputs.use_shared_vpc, false) fallbacks. When the stage-0 outputs are present and shaped as expected this works, but the resolution is fragile: if use_shared_vpc is absent or misshaped, the swallowed try() silently resolves the network name to ${prefix}-vpc in the main project rather than the actual shared-VPC network — which typically surfaces as a misleading not-found error (or, in edge cases, a silently wrong network). Passing host_project_id / network_name explicitly is the robust path, but that shouldn't be required for the standard shared-VPC case.

Environment and Deployment Context

• Stellar Engine Version/Commit: main at commit 3728fc98
• Deployment Type:
  • US Region Restricted (e.g., Access Policy constraint)
  • FedRAMP Medium
  • FedRAMP High
  • DoD IL4
  • DoD IL5
  • Stand-alone / Custom
• FAST Stage (if applicable): N/A — blueprint (blueprints/fedramp-high/gemini-enterprise/gemini-stage-1)
• Affected Component: gemini-stage-1/load_balancer.tf (lines 41–49)
• Terraform Version: 1.12.2 (pinned by deploy.sh for the Gemini deploy flow; stage not yet applied — finding verified by code inspection at 3728fc98)
• GCP Provider Version: not initialized — declared constraint >= 5.0

Steps to Reproduce

1. Deploy gemini-stage-1 against a stage-0 state whose use_shared_vpc output is absent (older state) or renamed.
2. terraform plan — the network data source resolves to ${prefix}-vpc in the main project instead of the shared-VPC network.

Expected Behavior

Shared-VPC network resolution is explicit and deterministic from stage-0 outputs, failing loudly if a required output is missing.

Actual Behavior

try() swallows the missing/misshaped output and falls through to the non-shared-VPC branch, producing a misleading not-found error against the wrong project/network.

Relevant Logs and Errors

Error: ... The resource 'projects/<main-project>/global/networks/<prefix>-vpc'
was not found

(Misleading: the operator's actual network exists — in the shared-VPC host project.)

Additional Context

Fix: read the shared-VPC decision and names from required (non-try) stage-0 outputs, or validate their presence with a precondition so the failure names the real cause. Related (not duplicate): #38 tracks a separate bug in this same file.