re(challenge): withdraw the kind-field constructor attribution -- snapshot refutes it

Section 4 claimed the mission-kind field at obj+144 "is initialised to 0 in the
constructor sub_821783D8, alongside +148 = 0, +132 = 2, +136/+140 = -1". That
linked two code regions on nothing more than both touching +144/+148, and an
in-flight snapshot refutes it:

sub_821783D8 initialises the STATIC at 0x828F3EC0 -- its first act is
InitializeCriticalSection(obj, 256) -- and in the snapshot that object holds
0x000B1C8B at +144 and a float at +592. Not a kind, not flags. So the object that
owns the kind field is UNIDENTIFIED. Scanning the snapshot for it (kind in
{0,3,5,6} at +144, stage 10 at +148, pointers at +0/+52/+604) returns only
matches inside the executable's own static data; the value 10 at +148 is far too
common to discriminate.

The switch itself stands -- it is direct disassembly at two independent sites
(0x82184df0, 0x82185ed0) plus two grouping tests. Only the attribution was wrong,
and the wrong half is the half I inferred rather than read.

Confirmed on screen instead: launching a story stage from MISSION SELECT reaches
a READY ROOM carrying an "EXTRA" watermark -- the EXTRA config section, kind 3,
visible in the UI. Independent evidence the field means what section 4 says even
though its owning object is not pinned.

docs/re/challenge-mission-gate.md

@@ -95,12 +95,29 @@ bgt  file            ; otherwise     -> "FILE"      (0x820A2168)
 
 Two further sites (`0x82186a60`, `0x82186cb8`) classify the same field as
 `{3, 5, 6}` versus everything else — i.e. **EXTRA and CHALLENGE together are "not an
-ordinary story load"**. The field is initialised to **0** in the constructor
+ordinary story load"**. Every write to `+144` inside this class (`0x82184b10`,
-(`sub_821783D8`, `0x8217851c`, alongside `+148 = 0` — the stage index — and
+`0x82185d48`, `0x82186ab4`) only *clears* it, and nothing in the image stores an
-`+132 = 2`, `+136/+140 = -1`), and every write to it inside this class
+immediate 3/5/6 into it, so the kind is **supplied from outside the class** — by
-(`0x82184b10`, `0x82185d48`, `0x82186ab4`) only *clears* it. Nothing in the image
+whichever GamePart launches the mission — not derived from the stage number.
-stores an immediate 3/5/6 into it, so the kind is **supplied from outside the class**
+
-— by whichever GamePart launches the mission — not derived from the stage number.
+> ⚠️ **Withdrawn:** this section used to add "the field is initialised to 0 in the
+> constructor `sub_821783D8`, alongside `+148 = 0`, `+132 = 2`, `+136/+140 = -1`".
+> That linked two code regions on nothing more than both touching `+144`/`+148`, and
+> a snapshot **refutes it**: `sub_821783D8` initialises the **static** at
+> `0x828F3EC0` (its first act is `InitializeCriticalSection(obj, 256)`), and in an
+> in-flight snapshot that object's `+144` holds `0x000B1C8B` and `+592` a float —
+> not a kind and not flags. So **the object owning the kind field is unidentified**.
+> Scanning the snapshot for it (kind ∈ {0,3,5,6} at `+144`, stage at `+148`,
+> pointers at `+0`/`+52`/`+604`) returns only matches inside the executable's own
+> static data — `10` at `+148` is far too common to discriminate. The **switch
+> itself stands**: it is direct disassembly at two sites. Only the constructor
+> attribution was wrong.
+
+**Confirmed on screen instead:** launching a story stage from MISSION SELECT reaches
+a READY ROOM carrying an **"EXTRA" watermark**
+([capture](captures/ready-room-extra-mode.png)) — the `EXTRA` config section, i.e.
+kind **3**, visible in the UI. That is independent evidence the kind field means what
+§4 says, even though its owning object is not pinned.
 
 ### 4.1 Why the stage-field probe crashes 🟡