[Bug] deploy.sh: brownfield CMEK auto-discovery assumes a project/keyring layout Stellar Engine FAST does not produce

## Bug Description
The brownfield CMEK discovery in the gemini-enterprise `deploy.sh` searches for a `cmek-*` project under a `StellarEngine-*` Assured Workloads folder (lines 592–607) and a keyring named `${CAP_ENV}-${TENANT}-keyring` (lines 614, 655, 775). Stellar Engine FAST actually creates security projects named `{prefix}-{prod|dev}-sec-core-0` under the **Security** folder, with keyrings named `prod-{location}` / `dev-{location}` (see `fast/stages-aw/3-security/core-prod.tf` / `core-dev.tf`). None of the discovery patterns match, so against a FAST-deployed foundation the script can never find the real workload key and either prompts for it or falls back to creating one in the wrong place.

## 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 tooling (`blueprints/fedramp-high/gemini-enterprise/deploy.sh`), interacting with Stage 3 outputs
* **Affected Component:** `blueprints/fedramp-high/gemini-enterprise/deploy.sh` (brownfield CMEK discovery, lines 592–618, 653–657, 775–783)
* **Terraform Version:** 1.12.2 (pinned by `deploy.sh`)
* **GCP Provider Version:** N/A — shell-script logic (the Stage 3 foundation it fails to discover was deployed with `hashicorp/google` 6.50.0)

## Steps to Reproduce
1. Deploy Stellar Engine FAST stages 0–3 (FedRAMP High), with `var.kms_keys` populated in 3-security so keys exist.
2. Run `deploy.sh` in brownfield mode against that foundation.
3. Observe "Could not find 'StellarEngine-*' folder" / "Could not find 'cmek-*' project" and the fallback behavior, despite valid workload keys existing in `{prefix}-{env}-sec-core-0`.

## Expected Behavior
Brownfield discovery finds the keys the framework's own Stage 3 creates (`*-sec-core-0` projects, `{env}-{location}` keyrings), or reads the key path from a Stage 3 output.

## Actual Behavior
Discovery patterns match nothing FAST produces; the operator must supply the key path manually or the script creates a key in the wrong place.

## Relevant Logs and Errors
```
Searching for 'cmek-*' project under 'StellarEngine-*' Assured Workloads folder...
Could not find 'StellarEngine-*' folder. Defaulting to .
```

## Additional Context
Proposed fix: align discovery with FAST security-project naming (`*-sec-core-0` / `{env}-{location}` keyrings), or read the key path from Stage 3's `kms_keys` output. This also keeps IaC state-encryption keys (tenant iac-core) cleanly separated from data/workload keys (security project) — the current fallback conflates the two.

Start in blueprints/fedramp-high/gemini-enterprise/deploy.sh, especially the brownfield discovery blocks at lines 592–618, 653–657, and 775–783. Compare those patterns with fast/stages-aw/3-security/core-prod.tf and core-dev.tf, then verify behavior against a FAST stages 0–3 foundation with populated kms_keys. Done means brownfield deployment discovers the security-project workload keys and no longer prompts or creates a key in the wrong location.

Written by the indexing model from the issue text.