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.

STATUS.md

@@ -1,9 +1,14 @@
 # STATUS — what works, what's broken, what's next
 
-**Updated 2026-09-06 (second pass) — I built a machine that upgrades a real app with real data in it
+**Updated 2026-09-06 (third pass) — I chased down the BookStack database problem I found this
+morning. Good news: it does not get worse, and fixing it costs seven seconds and loses us nothing.
+The catch I expected — that fixing it would stop us being able to go back — turned out not to be
+real. TWO THINGS NEED YOU: item 11 (how wide to take the upgrade testing) and item 12 (one small
+yes/no on the database setting).**
+
+**Earlier 2026-09-06 (second pass) — I built a machine that upgrades a real app with real data in it
 and then asks the app whether the data is still there. Three apps, five real upgrades: the data
-survived every time. It also found a genuine problem in our own BookStack setup. ONE NEW THING NEEDS
-YOU: item 11 — how wide should I take this?**
+survived every time. It also found a genuine problem in our own BookStack setup.**
 
 **Earlier 2026-09-06 — a restart no longer changes which version an app runs. Fixes still arrive
 every 15 minutes, and a broken app definition still repairs itself. Only the Update button moves a
@@ -36,7 +41,7 @@ not an evening's work.**
 *This section is allowed to be longer than one screen, and each item says what happens if you do
 nothing.*
 
-1. **One thing is waiting on you: item 11 (how wide to take the upgrade testing).** Item 4 (the Hetzner e-mails) is answered and is being handled in a separate session. Item 7 — the safety-copy decision — is the one open question, and it is **not urgent any more**: the thing that made it urgent was that a restart could upgrade an app behind your back, and as of today it cannot. Item 10 is new and needs nothing from you. Item 5's alarm mail can now be ignored for good. Otherwise: Both problems the overnight test found are fixed and proven on
+1. **Two things are waiting on you: item 11 (how wide to take the upgrade testing) and item 12 (a small yes/no about the database setting — I have measured both costs).** Item 4 (the Hetzner e-mails) is answered and is being handled in a separate session. Item 7 — the safety-copy decision — is the one open question, and it is **not urgent any more**: the thing that made it urgent was that a restart could upgrade an app behind your back, and as of today it cannot. Item 10 is new and needs nothing from you. Item 5's alarm mail can now be ignored for good. Otherwise: Both problems the overnight test found are fixed and proven on
    the real machines:
    - the background job that could delete a live restore's lock now waits its turn — and the check
      that finds the next one like it is a test, not a comment, so it cannot come back quietly;
@@ -231,6 +236,39 @@ nothing.*
     **If you do nothing:** nothing breaks. The machine is built and committed, so it does not go
     stale, and the BookStack problem is written down and waiting either way.
 
+12. **Shall I tell the database engine to finish its own conversion? One yes/no. It affects four
+    apps and I have measured both sides.**
+
+    **The background, in one line.** This morning I found that when BookStack's database engine moves
+    to a new major version, the engine says the conversion it needs is being **skipped** — and then
+    works anyway.
+
+    **What I measured this afternoon.**
+    - **It does not get worse.** I restarted it five times. The app answered correctly all five
+      times, and nothing changed for the worse.
+    - **But it never fixes itself either.** Every single time it starts, the engine says the check is
+      still needed. It will say that forever.
+    - **Fixing it takes seven seconds.** The engine backs itself up first, does the conversion, done.
+    - **And the catch I was worried about is not there.** I expected that converting properly would
+      mean we could no longer go back to the old version. **We still can** — I tried it, and the app
+      came back with its data.
+
+    **So this is not the difficult trade I thought I would be bringing you. It is a cheap tidy-up.**
+
+    - **Yes, turn it on.** Four apps get a correctly-converted database — BookStack, Kimai, Nextcloud
+      and RomM. Costs seven seconds the one time each of them moves a major version. **This is what I
+      would do.**
+    - **No, leave it.** Nothing breaks today. The engine keeps saying it wants a check, on every
+      start, indefinitely.
+
+    **One honest limit on my "yes".** I proved the app's normal use keeps working. I did **not** test
+    every database feature on an unconverted engine — so I can tell you it has not broken, not that
+    nothing can. That is exactly why leaving it alone is a real choice and not just laziness.
+
+    **If you do nothing:** nothing breaks and nothing is at risk this week. Only BookStack has
+    actually moved a major version so far; the other three will land in the same place when their
+    turn comes. I have not changed any template — this is your call, not a quiet edit.
+
 8. **`demo-hp`'s network setup does not match our own notes** (R-338) — the machine works, the page is
    wrong, or the other way round. **If you do nothing:** the page keeps misleading the next session,
    as it misled one by an hour.