re: the boot sequence is not data-driven -- closing Q6 with the negative

rather than leaving it amber

Q6's second half asked what the game READS to decide the boot order. The
answer is nothing, and the value here is the reach rather than a find.

Four places checked, the order in none of them: config.ini's [SYSTEM] is
empty and it is the disc's only config; the movie manifest carries the
boot-side assets but no transitions; the requested GamePart id was
already shown to exist only as a stack argument in flight, with no
persistent field and no literal store; and the string GP_ADVERTISE_DEMO
has zero xrefs of any kind, so nothing in the code reads the attract
entry of the id table. A transition is a call with an id argument.

Traced as far as it goes cheaply: the RegisterToFactory<0,
GamePart_Title> string is referenced from exactly one site,
sub_8280E148, which also takes the address of sub_821C7D98 -- where a
factory template puts its creator. Marked amber, because that is position
and convention rather than proof, and sub_821C7D98 has zero .rdata
references, which fits a new+ctor thunk and not a state machine. The
substantial function in that neighbourhood is sub_821C6458 and I did not
read it.

So Q6 closes as answered with the driver classified as code rather than
data, which means the port AUTHORS the sequence -- and that is fine,
because the sequence itself is measured end to end and the handoff now
carries it in one line.

docs/re/REFUTED.md

@@ -35,6 +35,9 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
+* "the boot sequence is driven by a table the game reads" → it is **not
+  data-driven**; four search spaces closed, transitions are calls with an id
+  argument. [`boot-config-and-gamepart-registry.md`](boot-config-and-gamepart-registry.md)
 * "`config.ini` is a GamePart settings table, so the boot order is in it" → its
   `[SYSTEM]` section is **empty**; the only populated section is `[LANGUAGE]`.
   [`boot-config-and-gamepart-registry.md`](boot-config-and-gamepart-registry.md)