Expand pg_tle testing into a full parallel dimension of the upgrade/update matrix

[jnasbyupgrade]

Background

pg_tle CI coverage (pg-tle-test/pg-tle-upgrade-test, from PR #47) currently proves: fresh
install via pg_tle, the in-place update path (0.2.2->current), and binary pg_upgrade for exactly
2 jumps (12->13, 12->18) -- all with zero filesystem trace verified via bin/assert_fs_clean.

The gap

Isolation (dedicated cluster, fs-cleanliness checks) is necessary for pg_tle testing to mean
anything, but it isn't the goal -- the goal is proving cat_tools works correctly under every
deployment path we already test for a filesystem install, not just a narrow smoke test. Right
now pg_tle testing covers a small subset of what the filesystem matrix covers:

• Binary pg_upgrade: pg-upgrade-test's actual jump matrix (currently 6 legs: 10->18 from
  0.2.0, 10->18 from 0.2.1, 11->12, 11->18, 12->13, 12->18 -- re-check the current matrix before
  implementing, it may have changed) has no pg_tle equivalent beyond 2 of those jumps.
• Stepwise pg_upgrade: pg-upgrade-stepwise (one cluster climbing every major in sequence)
  has NO pg_tle equivalent at all.

The one real constraint

pg_tle doesn't support every PostgreSQL major cat_tools does. Investigate and confirm before
implementing (don't assume from memory):

• pg_tle's actual minimum supported PostgreSQL major (pgxntool/pgtle_versions.md documents
  version-to-PG-major compatibility buckets).
• Whether pg_tle survives a binary pg_upgrade the same way any other in-database state does
  (its registration lives in the database being upgraded, which binary pg_upgrade migrates via
  catalog carry-over) -- confirm this holds, don't assume, by trying it once before building a
  whole matrix around the assumption.
• PG10 is almost certainly below pg_tle's floor entirely -- the PG10-origin legs (10->18 from
  0.2.0/0.2.1) likely have no pg_tle equivalent and should just be skipped, with a comment saying
  why, not silently omitted.
• Same question applies to a stepwise climb's starting point -- it would need to start wherever
  pg_tle's floor actually is, not PG10.

What to build

1. Expand pg-tle-upgrade-test's matrix to cover every jump pg-upgrade-test covers that's
   actually within pg_tle's supported range.
2. Add a pg_tle-based stepwise climb, mirroring pg-upgrade-stepwise's mechanics but starting
   from pg_tle's actual floor, using pg_tle registration instead of filesystem install at each
   step.
3. Update the "Test strategy" summary comment in ci.yml once implemented -- pg_tle should
   appear as a parallel column alongside the filesystem matrix for every category, with its
   narrower PG-major floor as the one explicit caveat.

Related

Distinct from #72 (testing the OLDEST supported pg_tle version, not more test categories at
the current version) -- that's a different axis, do them independently.

[jnasbyupgrade]

Clarifying note from the maintainer: we don't have to support the full range of pg_tle versions/PG-major combinations here. If narrowing cat_tools' claimed pg_tle-supported range (rather than forcing parity with the filesystem matrix everywhere) is the pragmatic outcome, that's fine -- don't treat matching the filesystem matrix 1:1 as a hard requirement.