Repurpose gps as GCP project switcher

[ikuwow]

Why

gps used to switch gcloud configurations, but only one real configuration ever existed (default for [email protected] / mo-app-stg). The prompt showed <GC:default> regardless of which project was actually being targeted, leaving no safety signal when 50+ projects (stg vs prd) are all reachable from one account. That makes ops mistakes (e.g. running a prd command while thinking you're on stg) easy.

The AWS side already solves the equivalent problem with aps + AWS_PROFILE + prompt_aws: a per-shell env var, visible in the prompt, with a fzf switcher. This change aligns GCP to the same pattern, with the axis being GCP project (account is single-tenant today).

Approach

• gps now lists gcloud projects list via fzf and exports CLOUDSDK_CORE_PROJECT for the current shell only. No disk state, no per-project configuration objects to maintain.
• gcloud projects list output is captured into a variable with an exit-status check before being piped, so auth / network failures surface as gps: failed to list GCP projects + exit 1 instead of being swallowed by the pipe and producing a misleading "No projects are selected." message.
• prompt_gc shows <GCP:project-id> when the env var is set, empty otherwise. Empty is intentional — it signals "no override active, gcloud falls back to the default configuration's project."
• AIRULES gains a peer rule to the AWS one: prefix gcloud / bq / gsutil with CLOUDSDK_CORE_PROJECT=<project> and confirm the project with the user before running.

CLOUDSDK_CORE_PROJECT is the documented env override for [core] project (gcloud's section/property → CLOUDSDK_<SECTION>_<PROPERTY> convention). Same mechanism extends to CLOUDSDK_CORE_ACCOUNT when multi-account support is needed later — the switcher and prompt can be extended without changing the underlying contract.

Out of scope

• The dummy none configuration that the old gps --clear relied on is no longer used. Cleanup is deliberately left for a separate PR.
• Multi-account selection. Designed for, not implemented in, this PR.

Verification

• bash -c 'source .functions; gps --help' shows the new help text
• bash -c 'source .functions; CLOUDSDK_CORE_PROJECT=mo-app-stg prompt_gc; echo $GC_PROMPT' → <GCP:mo-app-stg>
• bash -c 'source .functions; prompt_gc; echo "[$GC_PROMPT]"' (unset) → []
• bash -c 'source .functions; export CLOUDSDK_CORE_PROJECT=mo-app-stg; gps --list | grep -E "^\\* "' → * mo-app-stg
• bash -c 'export CLOUDSDK_CORE_PROJECT=mo-app-stg; gcloud config get-value project' → mo-app-stg (env var overrides active config)
• CLOUDSDK_CORE_PROJECT=mo-app-stg bq show --format=json | head -1 → returns the mo-app-stg project record (confirms bq honors the env var)
• CLOUDSDK_CORE_PROJECT=mo-app-stg gsutil ls → lists mo-app-stg buckets (confirms gsutil honors the env var; AIRULES claim is empirically validated for this environment)
• Simulated gcloud failure (gcloud() { return 1; }) → both gps --list and gps mo-app print gps: failed to list GCP projects to stderr and exit 1
• Open a fresh terminal tab, run gps, pick a project via fzf, confirm prompt updates and gcloud config get-value project reflects the choice
• In a second tab, gps --clear clears the env var and prompt indicator without affecting the first tab