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

## 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
* [x] 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//global/networks/-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.

Start in gemini-stage-1/load_balancer.tf lines 41–49 and inspect the stage-0 remote-state outputs used for shared-VPC resolution. Run terraform plan against a stage-0 state with the output absent or misshaped to confirm the misleading fallback. Done means missing required outputs fail clearly and valid shared-VPC deployments resolve the host project and network deterministically.

Written by the indexing model from the issue text.