fix(chargen): Campaign CC gate round 1 Batch C — Summary how-to + scrollbar linkage

Commit 3/3: Summary how-to text + Commit 2's owed scrollbar linkage +
bookkeeping sweep.

- Ports gmCGSummaryPage::SetHowToText @0x0047ae20 into the Summary
  page's how-to box (0x10000404, HowToTextId was declared and unused
  since CC5). Retail concatenates ID_CharGen_SummaryHowTo + a heritage/
  gender-specific name-suggestion list (heritages 1-4 — Aluvian/
  Gharundim/Sho/Viamontian — only; heritages 5-13's cases in the same
  switch decompile to a vtable-slot artifact, the same decompiler-
  mangled-symbol class the Heritage page's own BonusSkillsKeyByHeritage
  table already documents, so no name-suggestion string exists for them
  and none is invented) + ID_CharGen_SummaryHowToEnd, directly
  concatenated (no separator literal) into ONE plain SetText call — no
  per-run font/color argument, unlike Heritage's ...WithFont calls, so
  this routes through DatRichText as a single DefaultColor segment.

- Wires the description boxes' linked scrollbar to actual text
  scrolling — Commit 2 made the scrollbar child (0x100002e7) BUILD as a
  real UiScrollbar; this binds scrollbar.Model = text.Scroll, the exact
  pattern ChatWindowController already uses for the chat transcript.
  Live-DAT-measured: only Heritage's description (0x100003c4) and
  Summary's how-to box (0x10000404) actually author this child —
  Profession/Town's shorter description boxes do not (a genuine retail
  authoring fact, not something to "fix" further).

Register: AP-215/AP-216/AP-217 rewritten (Batch C's Commit 1 already
retired AP-218/AD-103) — no further changes needed this commit; ISSUES
#366 (chat's new-unseen-text indicator, 0x1000048C under the chat
transcript 0x10000011) NARROWED — its own pre-filed "fix shape"
recommendation (a UiText child carve-out mirroring UiMeter's) is
EXACTLY what Commit 2 shipped, confirmed by that commit's own
client-wide sweep; #366 stays open for the still-missing behavioral
half (no controller drives the indicator's visibility/click).

Findings doc updated: GF-2/GF-3/GF-4/GF-6/GF-11a/GF-12/GF-14's text
half all marked FIXED with their own root-cause notes; the two
remaining "suspected shared roots" (frames/labels, rich text) marked
CONFIRMED + CLOSED.

Full App suite (Debug and Release, live-DAT): 5307 passed / 0 failed /
3 skipped (up from 5304 after Commit 2). Runtime suite: 1735/0,
unaffected.

Campaign CC gate round 1 Batch C is CODE-COMPLETE across all three
commits — GF-2, GF-3, GF-4, GF-6, GF-11a, GF-12, and GF-14's text half
are fixed; AP-216/AP-217 partially closed (register-honest about what
shipped vs what needs a palette-to-RGB pipeline this batch didn't add).
Pending the user's visual gate, with chat + the main game UI flagged
for extra attention (Commit 2's client-wide blast radius).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/ISSUES.md

@@ -1791,29 +1791,25 @@ controllers read instead of the main window's private field.
 
 ## #366 — Chat window's new-unseen-text indicator (0x1000048C) imports but is never independently wired
 
-**Status:** OPEN — filed 2026-08-10, Campaign CH slice CH6a. The retail main
-chat window authors a 16×16 "new unseen text" indicator button
-(`0x1000048C`, base `0x10000527`/`0x21000040`) as a CHILD of the transcript
-text element `0x10000011` (position `(0,57)` relative to the transcript,
-i.e. bottom-left of the transcript pane), confirmed in the `0x2100006F`
-LayoutDesc dump. `UiText.ConsumesDatChildren` is `true` (Type-12 behavioral
-widgets reproduce their dat sub-elements procedurally per
-`DatWidgetFactory`'s own doc comment), so `LayoutImporter.BuildWidget`
-never builds `0x1000048C` as a separate widget — it is silently swallowed,
-same as under the wrong `0x21000006` layout before it (not a CH6a
-regression). No controller anywhere binds or drives its visible state.
-**Not in CH6a's scope** (transcript/input/scrollbar/1-4-buttons only) and
-not obviously CH6b/CH6c's either — files here as a standalone gap. Fix
-shape: either give `UiText` an opt-in mechanism to keep specific named
-non-Type-3 children (mirroring `UiMeter`'s existing text-overlay carve-out
-in `DatWidgetFactory.BuildWidget`), or handle `0x1000048C` as a special
-case the same way. Needs research first: what triggers retail's "new text"
-indicator (unread-since-scroll-position?) and what it visually does on
-click — not decoded by CH6a.
+**Status:** OPEN, NARROWED 2026-08-16 at Campaign CC gate round 1 Batch C
+Commit 2 — the BUILD half of this issue's own "fix shape" recommendation is
+now DONE. `LayoutImporter.BuildWidget` gained a `UiText`/`UiField`
+media-bearing-child carve-out (mirroring `UiMeter`'s own text-overlay
+carve-out, EXACTLY the shape this issue proposed) as part of a chargen
+description-box fix; the client-wide blast-radius sweep that fix's own
+tests run
+(`LayoutImporterMediaBearingChildSweepTests.MediaBearingChildSweep_EnumeratesEveryAffectedType12Element`)
+independently re-confirmed `0x1000048C` under `0x10000011` in layout
+`0x2100006F` as one of the affected elements — it now builds as a real
+widget instead of being silently swallowed. **Still open:** no controller
+binds or drives its visible state (STILL the original ask — what triggers
+retail's "new text" indicator, and what it does on click, remains
+un-researched); this issue stays open for that behavioral half.
 
-**Where:** `src/AcDream.App/UI/Layout/ChatWindowController.cs`;
-`src/AcDream.App/UI/Layout/LayoutImporter.cs`
-(`BuildWidget`/`ConsumesDatChildren` handling); `src/AcDream.App/UI/UiText.cs`.
+**Where:** `src/AcDream.App/UI/Layout/ChatWindowController.cs` (behavior,
+still missing); `src/AcDream.App/UI/Layout/LayoutImporter.cs`
+(`BuildWidget`'s new `UiText or UiField` carve-out — CLOSED the build half);
+`src/AcDream.App/UI/UiText.cs`.
 
 ## #367 — ChatCommandRouter's local-presentation fallbacks type-0x1A text still lands in the chat scroll, never the SpewBox