docs: correct the empty ship capture - nothing is broken, there was no ship on screen

The previous commit framed the empty capture as "the 3D draws never reach
CaptureShipDrawForRE" and proposed a static comparison to find out why. The
comparison was done and it refutes the framing.

The discriminator for ship geometry is stride=24 prim=4 with a large vcount -
xbg7-mesh.md records a real one as stride=24 vcount=10891 indices=18 prim=4. Not
"positions outside the screen rectangle", which is what I used and is a bad test:
a UI sprite placed at (137,308) passes it.

By the correct test this run's capture has exactly one prim=4 draw, a 6-vertex
full-screen quad, and the 2.9 MB file I was comparing against has NO prim=4 draws
at all. That file is a UI capture: 1303 of its 1582 draws are stride=24 prim=13,
which two other docs in this corpus already identify as the UI sprite shader. The
"1300 3D draws" it appeared to contain were UI sprite coordinates counted by the
bad test.

So the capture recorded exactly what was on screen. The tutorial's opening is an
empty starfield, the player's own ship and a HUD - no capital ship. And
ship-placement-runtime-capture.md has always stated the procedure: play into the
mission, frame the ship side-on, press F10.

What remains is therefore not a code question but a gameplay one: reach a real
mission and frame a capital ship. Worth stating that the original capture was
taken interactively on HW Vulkan, and this container runs lavapipe.

docs/re/BACKLOG.md

@@ -776,8 +776,16 @@ shader, all screen-space, none 3D — against a known-good 2.9 MB capture from a
 earlier session. The 8 000-draw budget was not the limit and the scene *was*
 rendering. ⚠️ The "cache refuted" claim above is **overstated**: this run used
 the same complete cache as `tut4` and got 0 crashes vs 11 497, so variance
-dominates. **Next (static, no emulator):** compare this capture's shape against
-the known-good one to find why the 3D draws never reach `CaptureShipDrawForRE`. 🔴 The resume-refused lead (1 663 on one
+dominates. 🔴 **Corrected:** nothing is broken. Ship
+geometry is `stride=24 prim=4` with a large vcount (`vcount=10891` for a real
+one); this capture has one `prim=4 vcount=6` quad and the 2.9 MB "known-good"
+file has **no `prim=4` at all** — it is a **UI** capture (1 303 of 1 582 draws
+are `stride=24 prim=13`, the UI sprite shader). The earlier "3D draws" test
+counted UI sprite coordinates as 3D. The capture recorded what was on screen, and
+the tutorial's opening has **no capital ship**. **What remains** is what the
+capture doc always said: play into a real mission and frame a ship side-on —
+gameplay driving, not a menu step, and the original was taken on HW Vulkan where
+this container has lavapipe. 🔴 The resume-refused lead (1 663 on one
 thread) is **REFUTED**: that thread did execute, and `KeWaitForSingleObject` /
 `NtWaitForSingleObjectEx` are `kHighFrequency`, which is unlogged unless
 `--log_high_frequency_kernel_calls=true` — so a parked thread is invisible and