re: WITHDRAW "the freeze requires the rasterizer" -- the control was not controlled

Driving the null backend blind, using the memory screen-id as the guide, to the
SAME screen the rendered run froze on (screen 4):

    guest churn   19 of 8,089,600 bytes in 4 s  (0.000%)
    Main XThread  0 ms CPU / 4 s, state S, wchan futex_do_wait
    log           AllocRange unable ... 134217728 bytes; guest throw

Frozen identically with no rasterizer at all.

The flaw is the comparison, not the data.  The earlier "control" measured the
null-GPU run while it was still in the MENUS and the lavapipe run AT the freeze,
then reported the difference as a backend effect.  The allocations I cited as
proof it had walked through the content load (114 -> 120) were menu-time
allocations.  A control needs both arms verified to be in the same state -- and
the memory screen-id built this same session is exactly what makes that
checkable, which I failed to use on the arm that mattered.

Withdrawn: "the freeze requires the rasterizer", "the fault is in the host
rendering path", and the hardware-Vulkan blocker that followed from it.  The
rendering question is no longer load-bearing.

Survives: the freeze happens on the first content load after the main menu, on
every route and BOTH GPU backends, with Main XThread futex-blocked at zero CPU
rather than spinning; and four runs froze with three different allocation
outcomes, so the 128 MB refusal is correlated but not necessary.

Also survives and is independently verified: the memory screen-id navigation,
now reproduced on a third run.  It is what exposed this error.

Open again: what is Main XThread waiting on?  Identify the futex and its holder,
carefully -- gdb perturbs this measurement.

docs/re/BACKLOG.md

@@ -6,6 +6,16 @@ unknown, what evidence exists, and what the first step would be. Move an item in
 
 ---
 
+## 🔴 ~~BLOCKER — the mission freeze is a software-rendering hang~~ WITHDRAWN (2026-08-26)
+
+> **Withdrawn the same day.** Driving the null backend blind to the *same* screen
+> shows it freezes identically — 0.000 % guest churn, `Main XThread` futex-blocked
+> at 0 ms CPU, same 128 MB refusal and throw. The earlier control compared a
+> null-GPU run still in the menus against a lavapipe run at the freeze, i.e. two
+> different game states, and reported the difference as a backend effect. **The
+> hardware-Vulkan blocker below does not apply** — rendering is not what is
+> blocking this. The text is kept for the reasoning.
+
 ## 🔴 BLOCKER — the mission freeze is a software-rendering hang (2026-08-26)
 
 The freeze that blocks every dynamic measurement is in the **host rendering