fix(gemini-enterprise): parse hyphenated tenant ids and the FAST tenant bucket name in brownfield discovery

[scottonix]

Description

Brownfield discovery in blueprints/fedramp-high/gemini-enterprise/deploy.sh does not recognise a standard Stellar Engine (FAST) tenant:

1. The tenant id is taken as the third hyphen-separated field of the project id (cut -d'-' -f3). FAST tenants are typically named with a hyphen (ten-1, ten-2), so for prefix-prod-ten-1-main-0 the tenant comes back as ten, every derived name (<prefix>-prod-ten-iac-core-0, the state bucket, the keyring) points at resources that do not exist, and discovery falls through to the "Standard Stellar Engine Landing Zone framework not detected" path. The tenant is now everything between the environment and the -main-0 suffix; an id that does not match the pattern yields an empty tenant, which the existing check already reports.
2. The state bucket check used the wrong name. It looked for <prefix>-<env>-<tenant>-iac-0, while 1-resman creates the tenant state bucket as <prefix>-tn-<env>-<tenant>-0 (branch-tenants.tf, module tenant-core-gcs), so the bucket was never found and a second one was created. Use the FAST name.

The remaining brownfield assumption — a us multi-region keyring named <Env>-<tenant>-keyring holding gcs and gemini-enterprise keys, where 1-resman creates a regional <Env>-<tenant>-keyring in regions.primary with gcs and default keys — is left as is; that is a design question rather than a parsing bug and I will open an issue for it separately.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

Deployment & Compliance Impact

• Applicable Regimes:
  • US Region Restricted (e.g., Access Policy constraint)
  • FedRAMP Moderate
  • FedRAMP High
  • DoD IL4
  • DoD IL5
  • General / All
• NIST 800-53r5 Controls: none affected.

Checklist

Code Quality & Reusability

• My code adheres to the Maximize Reusability principle. I have not redefined common elements and have reused existing base configurations and modules where possible.
• I have checked that no existing module or configuration in modules/ or fast/ can be leveraged for this change.
• My code follows the established naming conventions outlined in documentation/naming-convention.md.

Documentation

• I have updated the README.md of the modified module or blueprint. (Not applicable — the README does not describe the parsing.)
• I have added/updated documentation for inputs (variables) and outputs. (Not applicable.)

Security

• My change adheres to GCP security best practices and the principle of least privilege.
• I have ensured compliance with the targeted regime (FedRAMP Moderate, FedRAMP High, IL5, etc.).

Testing

• I have tested my changes locally.
• I have included details of my testing in this PR.

Testing Performed

• bash -n deploy.sh: OK. shellcheck -S warning: the same 17 pre-existing findings before and after, none introduced.

• The extraction, run on sample project ids:

  project id	environment	tenant (before)	tenant (after)
  acme-prod-ten-1-main-0	prod	ten	ten-1
  acme-int-ten-2-main-0	int	ten	ten-2
  sedev-prod-g4g-main-0	prod	g4g	g4g
  acme-prod-tenant-main-0	prod	tenant	tenant
  not-a-match	—	match	(empty → existing "Could not derive" path)

• Observed originally against a FAST deployment with tenants ten-1/ten-2: discovery reported the tenant IaC project as missing although <prefix>-prod-ten-1-iac-core-0 existed.