docs: record fire-detail page bug (react-meteor-data 0.2.16 vs React 18)

Browser verification of the Comments feature surfaced a pre-existing client
bug: fire-detail pages (/fire/*/:id) stay blank because the page's withTracker
subscription never reaches ready() and re-subscribes in a loop. Isolated it:
the publications ready fine when subscribed standalone, so it's client-side —
react-meteor-data@0.2.16 (React-15/16 era) misbehaving under React 18 for a
component that gates render on subscription.ready(). Fix = upgrade
react-meteor-data to 2.x (useTracker). Documented in UPGRADE.md; not yet done.

UPGRADE.md

@@ -307,6 +307,7 @@ MONGO_CONTAINER=tcef-mongo7 MONGO_SHELL=mongosh MONGO_PORT=27019 ./smoke/smoke.s
 | raven / flowkey:raven | 2.4 | @sentry/node + @sentry/browser 8.x | ✅ done — `flowkey:raven` (Sentry legacy SDK, dead on 3.x, spammed the boot log with 502s against the dead sentry.comunes.org) replaced by the modern SDKs behind the same `ravenLogger.log()` facade (6 call sites unchanged). Backend: **GlitchTip** self-hosted on `aaron` (Sentry-compatible DSN/API; Sentry proper needs 16 GB RAM, didn't fit), deployed via the Comunes ansible (`glitchtip.yml`, org "comunes" / project "tcef-web"), fronted at `https://sentry.comunes.org` (nginx on `assange` → `aaron:8000`). DSN set in `settings-development.json`; end-to-end verified (a test exception sent from the dev server showed up in GlitchTip within seconds). |
 | nodemailer | 4 | 6.10 | ✅ done — drop-in for our usage: `email.js` only calls `nodemailer.createTransport(MAIL_URL)` and reads `transport.options.auth.user` (in the production-only `from()` branch); both verified unchanged in v6. Sending goes through `ostrio:mailer` (MailTime 2.5), which is v6-compatible. |
 | Babel | 7 beta | 7 stable | ✅ done (escala 1) |
+| react-meteor-data | 0.2.16 | 2.x (useTracker) | ⚠️ debt — 0.2.16 is React-15/16-era; on React 18 its `withTracker` loops on the fire-detail pages (never-ready → blank). See "Known bug" above. Upgrade needed to fix fire-detail + Comments. |
 | i18next | 10 | current | debt — pin; not on the critical path |
 | Leaflet | 1.3.1 | current | debt — pin; not on the critical path |
 | arkham:comments-ui | 1.4.x | — | ✅ replaced with in-repo React feature |
@@ -323,3 +324,31 @@ compiles, but the comments UI itself is **not exercised by the smoke test**
 (it's not part of the Flutter REST contract). It needs manual staging
 verification: on a fire archive page — logged-in post/edit/remove, like/dislike,
 and image/YouTube embed.
+
+### ⚠️ Known bug: fire-detail pages don't render (blocks the Comments check)
+
+Browser-verifying the above surfaced a **pre-existing client bug**: the
+fire-detail pages (`/fire/{active,archive,alert}/:id`, component
+`imports/ui/pages/Fires/Fires.js`) stay blank — the page's `withTracker`
+subscription (`fireFromActiveId` / `fireFromId`) never reaches `ready()`, so
+`loading` stays true and nothing renders. It pegs a CPU core (re-subscribe
+loop). Since the Comments box only mounts once a fire renders, the Comments
+feature can't be verified until this is fixed.
+
+Diagnosis (isolated, not guessed):
+- **The publications are fine.** Subscribing to `fireFromActiveId` /
+  `fireFromId` *standalone* from the browser console (`Meteor.subscribe(...)`,
+  outside the page) readies immediately and delivers the doc. So the async
+  publications are correct — this is **not** a server/publication bug.
+- **The bug is client-side**, in the `Fire` component's `react-meteor-data`
+  `withTracker`: in the page context it re-subscribes in a tight loop and never
+  stabilizes to ready. Prime suspect: **`react-meteor-data@0.2.16`** — an
+  ancient version (React-15/16 era, `componentWillMount` + legacy context;
+  these are the deprecation warnings flooding the console) that misbehaves under
+  React 18 for a component that gates its whole render on
+  `subscription.ready()`.
+- Likely fix: upgrade `react-meteor-data` to a React-18-compatible release
+  (2.x, `useTracker`), which may need touching the `withTracker` call sites.
+  Tracked as debt below; not yet done.
+- Note: `/` and `/fires` (which also use `withTracker` but don't gate render on
+  `ready()`) render fine — so the app is usable, but fire-detail pages are not.