ci: use running postgres for pgschema desired-state planning

[wpfleger96]

Problem

The Desktop E2E Integration job flakes with:

Error: failed to start embedded PostgreSQL: no version found matching 18.0.0

This is a misleading error. ./bin/pgschema apply spins up a throwaway embedded Postgres (a Zonky binary downloaded from Maven Central) to build its desired-state catalog for the diff. The vendored fergusstrange/embedded-postgres library returns the literal string no version found matching %s on any non-200 response from Maven (timeout, 5xx, connection reset) — not just a true 404. The 18.0.0 artifact exists and resolves with HTTP 200, so this is a transient Maven Central fetch hiccup wearing a version-mismatch costume, uncorrelated with any code change. Blind reruns pass because the jar is genuinely there.

Fix

Point pgschema at the already-running docker buzz-postgres (postgres:18) container as its external plan database via PGSCHEMA_PLAN_* env vars on the existing Apply database schema step.

In File Mode (--file), apply binds PGSCHEMA_PLAN_* to the --plan-* flags, and CreateDesiredStateProvider returns the external-database provider before the embedded path that calls StartEmbeddedPostgres. The Zonky/Maven download is never entered, so Maven Central is removed from the job's critical path permanently — this deletes the flaky dependency rather than dampening it.

Desired-state is built in a timestamp + crypto-random-suffixed temp schema (pgschema_tmp_<ts>_<8hex>) that is dropped on exit; public is never written during the plan phase. Plan and target are the same postgres:18 container, satisfying pgschema's exact-major-version requirement.

[wpfleger96]

Proof obligation — verified

Both Desktop E2E Integration shards passed on this branch (run 27629140515), jobs (1/2) and (2/2). A blind green isn't the proof — here is the dispositive log evidence that the embedded/Maven path is gone.

1. The five PGSCHEMA_PLAN_* env vars are present on the Apply database schema step

PGSCHEMA_PLAN_HOST: localhost
PGSCHEMA_PLAN_PORT: 5432
PGSCHEMA_PLAN_DB: buzz
PGSCHEMA_PLAN_USER: buzz
PGSCHEMA_PLAN_PASSWORD: buzz_dev

2. Embedded-Postgres / Maven fetch is ABSENT

Grepping each job's full log for embedded, maven, zonky, repo1.maven, no version found:

job (1/2)  81700236369 — 0 matches
job (2/2)  81700236290 — 0 matches

The embedded path is the only code that reaches Maven Central (internal/postgres/embedded.go is the sole importer of fergusstrange/embedded-postgres and the sole caller of StartEmbeddedPostgres — the function that emits the failed to start embedded PostgreSQL flake string). Zero matches ⟹ that branch was never entered.

3. The desired-state plan was built with no download phase

The step output, start to finish in ~1.3s:

##[group]Run ./bin/pgschema apply --file schema/schema.sql --auto-approve   15:41:22.073Z
Plan: 41 to add.                                                            15:41:23.360Z
DDL to be executed:
Applying changes...
Executing group 1/1...
  Executing 126 statements in implicit transaction

No jar fetch, no embedded-PG boot — the external plan DB was used.

On the pgschema_tmp_* temp schema

The temp schema is created only by the external path (NewExternalDatabase.ApplySchema → CREATE SCHEMA "pgschema_tmp_<ts>_<8hex>", internal/postgres/external.go:103). Verified at source (v1.7.4): pgschema references the temp schema name in stdout only inside error messages (failed to create temporary schema %s, failed to apply schema SQL to temporary schema %s). On the success path it is never logged, so a green run cannot surface pgschema_tmp_* by grep — by design.

The temp-schema usage is therefore established by mutual exclusion: with the embedded/Maven path proven absent (#2) and a desired-state plan proven produced (#3), the external path is the only code that can have run — and the external path's desired-state catalog is built exclusively in the pgschema_tmp_* temp schema, dropped on exit. There is no third desired-state provider.