feat(chat): Campaign CH slice CH6a — retail chat-window layout + 8-grip resize

Swap ChatWindowController's imported main-chat LayoutDesc from the wrong
0x21000006 (an unrelated layout whose root and 800px resize bar appear
nowhere in the EoR gameplay UI) to retail's ACTUAL main chat window,
0x2100006F (window root 0x10000600, authored 410x100 — confirmed by a
direct DAT dump, found in dats.Local not dats.Portal). Every downstream
compensation that existed only to paper over the wrong import is deleted:
the hand-cropped 490px content width, the dropped 800px resize bar, the
9px transcript patch, the orphan-sibling pruning, the max/min-vs-scrollbar
overlap shift, and the scrollbar top-reclaim. The window now mounts with
RetailWindowChrome.Imported (0x2100006F's own 8 border/corner elements are
its complete chrome) instead of the universal nine-slice wrapper.

LayoutImporter/DatWidgetFactory gain a Type-9 (UIElement_Resizebar) case:
UiResizeGrip decodes retail's exact four-bool BorderLocation algorithm
(0x2A=bottom/0x2B=left/0x2C=right/0x2D=top,
UIElement_Resizebar::StartMouseResizing @0x0046B7E0) into a ResizeEdges
bitmask. A direct DAT dump established the true shape: only 7 of the 8
grip-position ids are Type 9 — the straight top-EDGE strip (0x1000069C) is
a Type-2 Dragbar (move handle), not a Resizebar, because the main window
has no title bar. UiRoot now gives a directly-hit grip's own edges
priority over its generic proximity heuristic, and a directly-hit move
handle the same priority over ambient proximity — so the plain top strip
moves the window while its two corner grips resize it including the Y
axis, and all 4 edges + 4 corners work everywhere else. This also fixes
the reported "no diagonal cursor at corners" (CursorFeedbackController's
existing RetailCursorCatalog cursor ids already matched the DAT exactly;
they just never received a genuine diagonal edge combination) and "cannot
grow in Y from the bottom-right corner" (the old NineSlice+crop mount's
indirection is gone; the Imported mount uses the DAT's real
minH=100/maxH=2000/minW=300/maxW=2000 directly).

The 8 cosmetic "_Locked" border-art twins default hidden (register row
AP-185 — retail's UiLocked-driven art swap between the two skins is not
ported; UiRoot.UiLocked continues to gate the underlying interaction
correctly either way). The 4 chat-window-1..4 indicator buttons import
generically (visible, inert) for CH6b to wire. The two hand-drawn
translucent-black tints on the transcript/input are removed now that
their parent panels draw their own authored background sprites.

Filed #366 (chat window's new-unseen-text indicator 0x1000048C is
swallowed by UiText.ConsumesDatChildren, pre-existing and out of scope).
Corrected the research doc's "all eight grips" claim against the direct
DAT dump. Full Release suite: 12,317 passed / 4 skipped / 0 failed.

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

docs/research/2026-08-09-chat-retail-window-shell.md

@@ -321,6 +321,26 @@ vtable+0x64 + `StopMouseResizing` → `UIElement::StopResizing @0x0045FD60`.
 edge and every corner, including the top and the top corners, on both the main
 and the floating chat windows.
 
+**CORRECTED 2026-08-10 at Campaign CH slice CH6a implementation.** This claim
+is wrong for the main window's plain TOP EDGE specifically, established by a
+direct `ElementDesc.Type` dump of the installed DAT (ground truth, not a
+decomp reading) of the 8 ids `0x1000069B`-`0x100006A2`: 7 of them are
+Type 9 (`UIElement_Resizebar`) as claimed, but `0x1000069C` — the straight
+top-edge strip between the two top corners — is Type **2**
+(`UIElement_Dragbar`), not Type 9. So retail's main chat window is
+resizable from every edge and corner EXCEPT the plain top strip, which is a
+MOVE handle instead (there is no title bar, so the top strip does double
+duty as the drag affordance). The two top CORNERS (`0x1000069B` UL,
+`0x1000069D` UR) are still genuine Resizebar grips carrying the top bool, so
+dragging from a corner still resizes the Y/top axis — only the straight
+edge in between does not. This is fully consistent with, and explains, the
+`UIElement_Resizebar::StartMouseResizing` cursor media dump: `0x1000069C`
+carries cursor `0x06006119` (the four-arrow MOVE cursor, matching
+`WindowMove`), not one of the two diagonal or the vertical resize cursor
+ids the seven true grips carry. Not independently re-verified for the
+floating-window layout `0x2100005B` (CH6b's scope); assume it needs the
+same direct-dump check rather than trusting this row for that layout too.
+
 ### 2.4 Min/max extents
 
 Retail reads them as ordinary integer attributes on the window element:
@@ -539,6 +559,15 @@ blob. Consequences for acdream:
 
 ### 5.2 Gap list
 
+**G1 and G2 are CLOSED as of Campaign CH slice CH6a (2026-08-10).**
+`ChatWindowController.LayoutId`/`RootId` now import `0x2100006F`/`0x10000600`;
+the crop/rebase/orphan-pruning compensations are deleted; `LayoutImporter`
+gained a Type-9 case (`UiResizeGrip`); `UiRoot` gives a directly-hit grip's
+own edges priority over its generic proximity heuristic; the main window
+mounts with `RetailWindowChrome.Imported` (0x2100006F's own border art is
+its chrome). The two subsections below are kept verbatim as the historical
+diagnosis — do not re-run this investigation.
+
 **G1 — Wrong LayoutDesc for the main window.**
 `ChatWindowController.cs:29` imports `0x21000006` with root `0x1000000E`.
 Retail's EoR main chat window is **LayoutDesc `0x2100006F`**, window element