Bump NEWEST to 18: PG18 confirmed installable in pgxn-tools image

The advanced-extension-testing doc's reference implementation
(cat_tools) is on NEWEST=18; this repo was still on 17. Rather than
assume pg-start's `apt.postgresql.org.sh -i -p -v "$PGVERSION"` can
install PG18 (a matrix expansion that silently failed to install would
be a much worse failure mode than not bumping), confirmed it via an
actual CI run: pushed NEWEST=18 alone first and watched the new
"PostgreSQL 18" job -- it installed postgresql-18 18.4-1.pgdg13+1 via
pg-start and the full fresh-install suite passed.

With NEWEST=18, also shifted pg-upgrade-test's "newest-boundary" leg
from 16->17 to 17->18 and its "oldest-to-newest" leg from 10->17 to
10->18, keeping both legs matching the job's own stated rationale
(widest catalog distance; most likely to hit a *new* major's catalog
change first) now that 18 is the newest major instead of 17.

Author: jnasbyupgrade

.github/workflows/ci.yml

@@ -140,7 +140,7 @@ jobs:
           # `test` and `pg-upgrade-test` matrices below both derive their
           # version lists from here, so they cannot silently drift onto
           # different lists. To add or drop a major, edit only NEWEST/FLOOR.
-          NEWEST=17
+          NEWEST=18
           FLOOR=10
           supported=$(seq "$NEWEST" -1 "$FLOOR")
           # Emit a JSON array from a list of ints, for matrix: to consume
@@ -220,9 +220,9 @@ jobs:
       matrix:
         include:
           - old_pg: "10"
-            new_pg: "17"
-          - old_pg: "16"
-            new_pg: "17"
+            new_pg: "18"
+          - old_pg: "17"
+            new_pg: "18"
     name: 🔄 Binary pg_upgrade ${{ matrix.old_pg }} → ${{ matrix.new_pg }}
     runs-on: ubuntu-latest
     container: pgxn/pgxn-tools