fix(chat): CH2 rework — SpewBox tick-driven visibility + binary-derived error table

Reworks Campaign CH slice CH2 per the REJECT-review findings doc
(docs/research/2026-08-09-ch2-review-findings.md).

BLOCKER 1 — SpewBoxController never rendered a line and leaked its
pending queue. LinesProvider only ran through UiText.OnDraw, which
gates on Visible — and the box started invisible, so the provider (the
sole caller of SpewBoxState.Tick) never ran. Gave the controller an
explicit per-frame Tick(now) driven by UiRoot's global-message-3
broadcast (a zero-size GlobalTimeSink child, the same pattern
VendorUiController.DragOverGlobalTimeSink already uses), matching
retail's gmSpewBoxUI::Update. LinesProvider now only returns the
cache. Tests rewritten to drive root.Tick(...) instead of calling the
provider directly, plus new coverage for visibility-without-a-draw,
queue-drain-without-a-draw, and bounded-queue-across-many-ticks.

BLOCKER 2 — re-derived the HandleFailureEvent routing table from the
PDB-paired binary instead of the pseudo-C's ~33-char string previews.
tools/pdb-extract/sweep_weenie_strings.py sweeps every push imm32 in
VA 0x571990-0x575480, dereferences into .rdata/.data, and decodes the
full UTF-16LE literal. Added the 5 ids dispatched via else-if (missed
by case-label enumeration), resolved 0x4F8 (previously excluded),
fixed 18 wrong strings (16 the review flagged + 2 more — 0x4E9 and
0x518 — an automated diff between every swept literal and the landed
table found). Every changed row cross-checked against ACE's
WeenieError/WeenieErrorWithString enum doc comments; both oracles
agreed on every row, including a case where the review's own proposed
text for the new 0x4E8 row was itself wrong (it was 0x4E9's text) —
corrected via the else-if block's own instruction address plus the ACE
cross-check. Pinned table count: 344 (338 + 5 + 0x4F8).

SHOULD-FIX 1 — RuntimeCommunicationState.ResetSpewBox was dead code;
folded into the ChatIdentity generation-reset stage (same lifetime
boundary), with a reset assertion added to the existing populated-reset
test.

SHOULD-FIX 2 — AddText trimmed only the trailing end and invented an
empty-string early return; retail's AddTextToScroll trims both ends
(trim(&str, 1, 1, ws)) and has no empty guard. Both retired.

SHOULD-FIX 3 — ShowWeenieError bypassed the AddText chokepoint via
ChatLog.OnWeenieError (hardcoded LogTextType 0x00); routed through
Communication.AddText(Resolve(code, param)) instead, and
ChatLog.OnWeenieError is deleted — GameEventWiring's legacy no-router
fallback now resolves + calls OnSystemMessage directly.

SHOULD-FIX 4 — retail's HandleFailureEvent switch has no default case;
an unmapped id now resolves to a null Text (silence toward the
player) instead of the invented "WeenieError 0xNNNN" hex fallback,
with a diagnostics-only console log line for the id.

NITs — AP-TBD placeholders corrected to their real register rows
(AP-178, not the unrelated AP-177 lifetime row); filed AP-180 for the
windowId dual-destination gap and corrected three stale "lands with
CH2" comments; extended SpewBoxLayoutDumpDiagnostic from dats.Portal
to dats.Local and found the SpewBox element for real — LayoutDesc
0x21000011, element 0x10000048, size 450x72, MaxConcurrentItems
(ListBox property 0x10000028) = 4, not retail's code default of 1.
AP-178 narrowed accordingly; SpewBoxState.MaxConcurrentItems and
SpewBoxController's extent/anchor/OneLine are now authored rather than
placeholder (absolute screen position and colour remain open); fixed
the "19 ids... lists 18" miscount by retiring the stale paragraph in
the class doc rewrite; aligned the UseDone handler's silent-status
check with the other two WeenieError handlers.

Full Release suite: 11,914 passed / 4 skipped / 0 failed (build 0
errors).

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

src/AcDream.UI.Abstractions/Panels/Chat/ChatVM.cs

@@ -118,9 +118,24 @@ public sealed class ChatVM : IDisposable
     /// general-purpose output — @version, /loc, friends list, usage lines —
     /// and retail types the great majority of that informational command
     /// output <c>0x00</c>, reserving <c>0x1A</c> (bright red) for genuine
-    /// refusals/errors. The refusal-vs-informational split lands with CH2's
-    /// producer rewiring (SpewBox routing) — see
-    /// <c>docs/research/2026-08-09-chat-retail-interface-text.md</c> §7.2.
+    /// refusals/errors.
+    /// </remarks>
+    /// <remarks>
+    /// <b>Comment corrected 2026-08-09, CH2 REJECT-review rework (NIT 2,
+    /// docs/research/2026-08-09-ch2-review-findings.md):</b> the earlier
+    /// wording claimed the refusal-vs-informational split "lands with CH2's
+    /// producer rewiring" — it did not. CH2's SpewBox routing covers
+    /// <c>WeenieError</c>/<c>WeenieErrorWithString</c> ids, which carry their
+    /// own resolved <c>RetailLogTextType</c>; this sink takes plain
+    /// pre-formatted TEXT with no error code attached, so
+    /// <c>WeenieErrorMessages</c> has nothing to classify here. Per-call-site
+    /// classification of THIS sink's callers (which specific
+    /// <c>ClientCommandController</c> lines are genuine refusals retail
+    /// would type <c>0x1A</c>) remains unstarted, and even a classified
+    /// caller would still need retail's <c>windowId</c> dual-destination
+    /// echo (see register row AP-180) to land in both the SpewBox and the
+    /// command's originating chat window — out of scope for CH4/CH5, not
+    /// CH2.
     /// </remarks>
     public void ShowSystemMessage(string text) => _log.OnSystemMessage(text, chatType: 0x00u);