Google AlloyDB support (Postgres-family warehouse variant)

[ihistand]

Add support for Google AlloyDB, GCP's PostgreSQL-compatible database. AlloyDB is wire-compatible with Postgres, so it slots into the existing Postgres-family adapters — most likely as a thin variant that extends the postgres adapter, exactly the way supabase does (SupabaseExecutionSql extends PostgresExecutionSql).

Scope

1. Baseline — does warehouse: postgres already work against AlloyDB?
AlloyDB speaks the Postgres wire protocol, so the existing postgres adapter should largely work as-is once connected. First step is to confirm: point a warehouse: postgres project at an AlloyDB instance and run the integration suite. Document what works / what breaks. This may cover 90% of the need with zero new adapter code.

2. First-class warehouse: alloydb variant (if warranted).
If/when AlloyDB-specific surface is worth first-classing, add it as a variant extending postgres (mirror the supabase pattern):

• New adapter triad: AlloyDbExecutionSql extends PostgresExecutionSql + AlloyDbDbAdapter + a resolveTarget branch, dispatched in cli/api/dbadapters/execution_sql.ts.
• Accept warehouse: "alloydb" in workflowSettingsAsProjectConfig (core/main.ts — currently rejects unknown warehouses).
• AlloyDbConnection cred shape in protos/configs.proto (likely just the PostgresConnection shape + AlloyDB connectivity fields).

AlloyDB-specific surface to consider (the reasons to go first-class)

• Connectivity: AlloyDB is typically reached via the AlloyDB Auth Proxy or the Node.js AlloyDB Connector (private IP / IAM), not a bare host:port. The adapter/credentials may need to support that connection path rather than only a plain DSN.
• IAM database authentication — AlloyDB supports IAM auth (short-lived tokens, no stored password). This dovetails with the Cloud zero-credential-custody strategy (keyless / WIF) — AlloyDB + IAM is a natural keyless target.
• Columnar engine — AlloyDB's analytical accelerator; potential table-option surface.
• Vector / AI — pgvector plus the ScaNN index (alloydb_scann) and google_ml_integration for embeddings. Parallels the Supabase vector_index action; a vector_index variant could emit ScaNN DDL.

Notes

• Positioning fit: AlloyDB is a Postgres-family, GCP-native, analytics+AI database — squarely on the "analytics engineering for Postgres" wedge, and a clean third Postgres variant after postgres / supabase.
• Respect the single-write-warehouse rule (one R/W warehouse; AlloyDB would be that warehouse for an AlloyDB project).
• Reference pattern: supabase extending postgres — cli/api/dbadapters/{postgres,supabase}*.ts, the resolveTarget branch, and the warehouse whitelist in core/main.ts.