SPIKE R-459: the skipped MariaDB conversion is stable, and the trade it implied does not exist

Outcome A, qualified. Not B and not C.

It does not degrade: 5 of 5 restarts of 12.3 on an 11.6 datadir, readback passed
every time, mariadb_upgrade_info unchanged, the entrypoint line never escalated
past [Note]. It also never heals - the engine answers 'Major version upgrade
detected from 11.6.2-MariaDB to 12.3.3-MariaDB. Check required!' on every start
and will forever.

The trade R-459 was expected to produce is not real. Converting properly SUCCEEDS
across the multi-major jump, takes 7 seconds, backs up the system database
unasked - and putting 11.6 back afterwards STILL starts and serves the data. So
the operator is being handed a cheap correction, not a choice between a correct
engine and a reversible one.

The exit-code polarity was measured rather than read: 0 means the upgrade IS
needed, 1 means it is not. Assuming either the flag name or the polarity would
have inverted the headline. And run without credentials the same command returns
a confident-looking FATAL ERROR that is an auth failure.

R-464: after converting and going back, the entrypoint prints 'MariaDB upgrade
not required' on a state the same engine calls an unsupported downgrade. The
obvious cheap instrument for R-459 would have been to grep for that line, and it
would have reported fine for the broken case.

R-463: the PostgreSQL analogue, deliberately NOT measured here. 11 templates, 8
on postgres:16-alpine, register grep for pg_upgrade returns zero. The two engines
fail in OPPOSITE directions - MariaDB skips quietly, Postgres refuses to start -
so that one cannot hide; it presents as eight apps down at once.

No template changed. Teardown all three layers, hub checked rather than asserted,
local-lvm 30.53 percent before and after.

documentation/architecture/09-update-architecture.md

@@ -299,6 +299,36 @@ measure it" and "it does not work" are different facts, and only one of them is
 **`migration_observed` is a quoted line, never an inference from timing** — the value of both the
 Nextcloud and the docmost findings was the exact sentence the app printed.
 
+### Database engines under an upgrade — MEASURED 2026-09-06
+
+**The arc's standing rule that an engine change gets its OWN edge now has measured evidence behind
+it**, and the evidence is stronger than the rule's original argument. The rule was justified by
+*"two migrations behind one edge is an unreadable failure when it breaks"* — a readability argument.
+What was measured is that **an engine change can be applied and silently NOT happen**, which the
+app-half edge cannot produce and which no amount of readability would have surfaced:
+
+- `SPIKE-upgrade-test-2026-09-06.md` §4 — MariaDB 12.3 starts on an 11.6 datadir, logs that the
+  conversion it requires was **skipped**, and serves. **Assigned to the engine half by decomposition:**
+  the app half alone produces no such line.
+- `SPIKE-r459-mariadb-upgrade-2026-09-06.md` — it is **stable but never self-resolving** (5 of 5
+  restarts, no degradation, and the engine says `Check required!` every time, forever). Converting
+  properly **succeeds**, costs **7 s**, takes its own system-database backup, and **does not** cost the
+  ability to abort. **The trade that was expected here does not exist.**
+
+**Two rules for anything this arc builds around a database engine:**
+
+1. **Ask the engine, not the log.** MariaDB's entrypoint prints `MariaDB upgrade not required` on an
+   unsupported **downgrade**; `mariadb-upgrade --check-if-upgrade-is-needed` names it exactly
+   (**R-464**). A cheap instrument built on the log line would report "fine" for the broken case.
+2. **The two engines fail in opposite directions, so one check will not do.** MariaDB starts anyway
+   and skips quietly; **PostgreSQL refuses to start** on a datadir from an older major, and the image
+   performs no `pg_upgrade`. Eleven templates carry PostgreSQL and **eight sit on `postgres:16-alpine`**
+   (**R-463**).
+
+**And an engine-state field belongs BESIDE a verdict, never inside it.** `upgrade-test.py` reports
+`engine_state_after` next to `verdict`, because an unconverted datadir is not *known* to be a failure
+and a verdict that said so would encode an unproven judgement.
+
 **The rule slice 6 inherits, recorded now while it is cheap:** an engine change gets its own edge,
 never bundled with an app version bump. `bookstack` moved the application *and* MariaDB 11.6 → 12.3 in
 one commit (`0b73e5e`); that is two migrations behind one edge, and an unreadable failure when it