docs: confirm Mongo 3.2 ceiling = Meteor 2.5 (2.6 driver 4.x rejects wire v4)

Empirically verified: 2.4 and 2.5 green against mongo:3.2 (npm-mongo 3.9.1);
2.6 bumps npm-mongo to 4.3.1 which refuses MongoDB < 3.6
(MongoCompatibilityError, wire version 4). Branch lands on Meteor 2.5.

UPGRADE.md

@@ -10,11 +10,13 @@ Production runs against the shared replica set **rsmain on MongoDB 3.2.11**.
 Meteor 3 ships the modern `mongodb` Node driver, which requires a server
 **≥ 4.2/4.4**. Meteor **2.x still works against Mongo 3.2**.
 
-Therefore this branch stops at the **highest stable 2.x** with everything green,
+Therefore this branch lands on **Meteor 2.5** — empirically the highest release
-and the `meteor update --release 3.x` step is **deliberately not taken** until
+whose bundled `mongodb` driver still connects to Mongo 3.2 (2.6 bumps the driver
-the Comunes infra team upgrades rsmain (shared infra — coordinated in a separate
+to 4.x and fails; see "Escala ceiling" below) — with everything green. The
-phase, not unilaterally). The 2.x server code is migrated to async/await ahead
+`meteor update --release 3.x` step (and even 2.6+) is **deliberately not taken**
-of time so the final 3.x jump is mechanical.
+until the Comunes infra team upgrades rsmain (shared infra — coordinated in a
+separate phase, not unilaterally). Server code should still be migrated to
+async/await before the final 3.x jump so it is mechanical (tracked as debt).
 
 ## ⚠️ Deploy-ordering dependency: notifications cutover
 
@@ -155,15 +157,30 @@ historically). It was fully worked around by removing the dead build plugins
 above. If a future escala hits it again, build in a container matching the
 deploy target (Debian) rather than on this host.
 
-## Escala ceiling vs Mongo 3.2
+### Escalas 2.4 & 2.5 — ✅ green
 
-Meteor bumps the bundled `mongodb` Node driver to **4.x at Meteor 2.5**, which
+`meteor update --release 2.4`, then `--release 2.5`. Both trivial; `npm-mongo`
-drops support for servers **< 3.6**. Production's rsmain is **Mongo 3.2**.
+stays at **3.9.1** (mongodb driver 3.x). REST smoke byte-identical against
-Therefore the highest Meteor that can talk to the current production DB is
+`mongo:3.2` on both.
-**~2.4** (npm-mongo/driver 3.x). The smoke test runs against a real `mongo:3.2`,
+
-so the exact ceiling is verified empirically: it stays green through 2.3;
+## Escala ceiling vs Mongo 3.2 — **landing on Meteor 2.5** (empirically verified)
-2.5+ is expected to fail at connection time. **Landing target: highest 2.x that
+
-keeps the smoke test green against Mongo 3.2.**
+Meteor bumps the bundled `mongodb` Node driver to **4.3.1 at Meteor 2.6**, which
+requires server wire version ≥ 6 (**MongoDB ≥ 3.6**). Production's rsmain is
+**Mongo 3.2** (wire version 4). Verified directly by booting 2.6 against a real
+`mongo:3.2`:
+
+```
+MongoCompatibilityError: Server at localhost:27018 reports maximum wire
+version 4, but this version of the Node.js Driver requires at least 6
+(MongoDB 3.6)
+=> Exited with code: 1
+```
+
+So **Meteor 2.5 is the highest release that runs against the production Mongo
+3.2** (npm-mongo 3.9.1). That is where this branch lands: everything green, REST
+smoke byte-identical. Going past 2.5 (to 2.16 or 3.x) is gated on upgrading the
+shared rsmain replica set to Mongo ≥ 4.4 first — the same DB blocker as 3.x.
 
 ## 🚧 3.x — blocked (do not run `meteor update --release 3.x`)