fix: rewire postgresVersion input in pg_upgrade publish workflows

[jfreeland]

What kind of change does this PR introduce?

Bug fix

What is the current behavior?

The postgresVersion workflow_dispatch input was left as dead code after #2035 . The input is accepted but silently ignored. The workflows always read postgres_major and postgres_release from the current checkout's ansible/vars.yml.

The same issue exists in both publish-nix-pgupgrade-scripts.yml and publish-nix-pgupgrade-bin-flake-version.yml

What is the new behavior?

When postgresVersion is set (via workflow_dispatch or gh workflow run from ami-release-nix.yml), it is treated as a bare git tag name (e.g. 17.6.1.137, 15.14.1.137). The workflow:

1. Validates the tag exists (git rev-parse --verify), failing with a clear error if not
2. Reads postgres_major from that tag's ansible/vars.yml to determine which versions to iterate over
3. Reads postgres_release from that tag's ansible/vars.yml to determine S3 path version strings
4. Tarball/flake-version content always comes from the current checkout, only the version label is read from the tag.

When postgresVersion is not set, behavior is unchanged. We read from the current checkout's ansible/vars.yml.

Additional context

This enables publishing updated pg_upgrade scripts for historical releases whose ansible/vars.yml may have had a different set of postgres versions. Handle input as environment variable to avoid shell injection and -eo pipefail to guard against null.