extension-update-test and pg-upgrade-test don't exercise TEST_SCHEMA (only fresh install does)

[jnasbyupgrade]

Problem

PR #54 added a TEST_SCHEMA axis to the base test job — proving CREATE EXTENSION
and the make -> PGOPTIONS -> GUC -> psql pipeline work correctly whether or not a schema
is targeted first, most importantly proving cat_tools works when it is NOT on
search_path at all (the empty-TEST_SCHEMA case). But that axis only runs against a
FRESH install. Neither extension-update-test (in-place ALTER EXTENSION UPDATE) nor
pg-upgrade-test/pg-upgrade-stepwise (binary pg_upgrade) currently vary
TEST_SCHEMA at all — both only ever exercise the ambient/default schema case.

This matters because U&U testing exists specifically to catch behavior that diverges
depending on how an install was reached (fresh vs. updated vs. upgraded), and
schema-targeting is exactly the kind of thing that could behave differently across that
divide — e.g. a stale search_path assumption baked into an old update script, or a view
rebuilt during an update that silently starts assuming its own schema is on search_path.
Testing schema variation only on fresh install leaves that whole update/upgrade surface
unchecked.

Proposed approach — don't blow out the CI matrix

Per the "collapse the axis at the make level instead of crossing it into the CI matrix"
pattern already used for the base test job (test-long, looping TEST_SCHEMA values
through verify-results), this should NOT be added as new CI matrix legs — that
multiplies job count for an axis that's orthogonal to which environment the job runs in.
Two different mechanisms need two different fixes:

• extension-update-test (in-place update): likely straightforward. TEST_SCHEMA and
  TEST_LOAD_SOURCE=update are already independent, composable GUCs —
  test/install/load.sql already applies TEST_SCHEMA before mode selection. Extending
  test-long-style looping to also cover the update case should mostly be wiring, not
  new plumbing, but needs confirming bin/test_existing's update-scenario/
  update-check flow (which drives this job) actually threads TEST_SCHEMA through to
  its run_suite call.
• pg-upgrade-test / pg-upgrade-stepwise (binary pg_upgrade): harder. The schema has
  to be targeted at INITIAL install time, before the binary pg_upgrade runs —
  bin/test_existing's old-cluster install step needs to support installing into a
  specific schema, and the job then needs to exercise both schema cases without doubling
  the CI matrix leg count (old_pg x new_pg x origin is already a real matrix). Loop
  it inside the existing job — same runner, same leg, both schema variants run
  sequentially — rather than adding test_schema as a new matrix dimension.

Distinct from existing issues

Not #29 (that's about running the suite against the actually-upgraded objects at all,
already the subject of pg-upgrade-test's "existing" mode) — this is specifically about
adding the TEST_SCHEMA axis within that testing, on top of whatever #29 covers.