re: an embedded .prt part is a top-level RATC bundle, addressed by its element prefix

Read first: ui-rat-layout.md OWNS the RATC stack and already documents
the 60-byte element declaration table and 'one bundle = one
(context x language) build of that screen'.  What it does not say is how
a part is addressed when it is NOT a pak entry.

The elements of one bundle share a common name prefix, and that prefix
is the part name.  GP_MAIN_GAME_E2D.pak has 130 bundles with 114
distinct element prefixes -- pgmenu_btn00, pghud_wing, pgface,
pghud_range, pgmanuva_eff0 -- exactly the in-game part names.

The 100 in-game-only .prt names match a 2D bundle prefix 68 times; the
control, the 241 shipped parts, matches ZERO.  The two families are
disjoint on the test.  13 shipped parts match a bundle prefix in their
own screen pak, which is the expected shape.

Four of the five mission banners land here: pgmsg_start.prt is E2D
bundle 0x89fac252, a one-element bundle declaring pgmsg_start_sub.rat;
likewise _end_, _failed_, _restart_.  pgmsg_update has no bundle at all,
consistent with having no _sub.rat.

32 in-game names still have no 2D bundle.  They cluster into families
whose base name is a bundle, reading as a variant declared inside a
parent bundle -- a reading, not adopted.

Artefact +38 lines / 0 deletions; the other six regenerate
byte-identical.

docs/re/structures/mission-script-manifest.md

@@ -156,7 +156,43 @@ yet absent — `pgmenu_btn*` / `pgmenu_item*` / `pgmenu_pad`, `pgfacewin*`,
 drawn from the in-game bundles. Consistent with the split above; not separately
 proved.
 
-**Still not settled**: where the embedded parts sit *inside* a bundle. What is
+### ✅ An embedded part IS a top-level RATC bundle, named by its element prefix
+
+[ui-rat-layout](ui-rat-layout.md) owns this stack and already says a top-level
+RATC bundle is *"one (context × language) build of that screen"* with a 60-byte
+element declaration table at `0x20`. What it does not say is **how a part is
+addressed when it is not a pak entry**. It is addressed by the bundle itself:
+the elements of one bundle share a common name prefix, and **that prefix is the
+part name**.
+
+`GP_MAIN_GAME_E2D.pak` holds **130** bundles with **114** distinct element
+prefixes — `pgmenu_btn00`, `pghud_wing`, `pgface`, `pghud_range`,
+`pgmanuva_eff0`, … i.e. exactly the in-game part names.
+
+| | matches a **2D** bundle prefix | matches any bundle prefix |
+|---|---:|---:|
+| the 100 in-game-only `.prt` | **68** | 68 |
+| **CONTROL** the 241 shipped `.prt` | **0** | 13 |
+
+**0 of 241** is what makes this a result rather than a coincidence: the two
+families are disjoint on the test. (The 13 are shipped parts matching a bundle
+in their *own* screen pak, which is expected.)
+
+Four of the five mission banners land here: `pgmsg_start.prt` is the E2D bundle
+`0x89fac252`, a one-element bundle declaring `pgmsg_start_sub.rat`; likewise
+`_end_` `0x92239624`, `_failed_` `0xc01017fc`, `_restart_` `0x606fef65`.
+**`pgmsg_update` has no bundle at all** — consistent with it having no
+`_sub.rat` either.
+
+🟡 **32 in-game names still have no 2D bundle** (listed in the artefact). They
+visibly cluster into families whose *base* name is a bundle — `pghud_wing_act_*`
+beside `pghud_wing`, `pghud_range_*` beside `pghud_range`, `pgmanuva_eff1..3`
+beside `pgmanuva_eff0`, `pgtarget_*` — which reads as "a variant declared inside
+a parent bundle rather than a bundle of its own". **A reading, not adopted**;
+nothing here shows the variant mechanism.
+
+**Still not settled**: those 32, and `pgmsg_update`, which is absent from every
+route tried. What is
 now settled is that they are **not** pak entries while 241 of their siblings are,
 and that `pgmsg_update` is the odd one out even among them.