docs(D.2b): add strategic-purpose section to widget-generalization design

Capture the 'why beyond chat' the user articulated: chat is the proving ground;
the real payoff is inventory/spell-bar/vendor/character-sheet/trade becoming
data-driven assembly + thin controller. Notes what carries forward (the generic
widget toolkit + the find-by-id controller pattern) vs what those windows still
need (ListBox/Panel + Field drag-drop, the window-manager half of Plan 2, and
per-domain item/container data).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/superpowers/specs/2026-06-16-d2b-widget-generalization-design.md

@@ -51,6 +51,41 @@ real widget type) **dissolves**: the resolved Type is already correct. The facto
 just needs to *register* generic widgets for those Types instead of skipping them
 or dropping to `UiDatElement`.
 
+### 1.2 Why this matters beyond chat (the strategic purpose)
+
+Chat is the **proving ground**, not the destination. The payoff is that every
+future panel — **inventory, spell bar, vendor, character sheet, trade, skills** —
+becomes *assembled from dat data + a thin controller* instead of being hand-built
+from scratch. That is exactly how retail did it (`gm*UI::PostInit` everywhere on a
+shared `UIElement` toolkit), and it is the reason to do this pass carefully now.
+
+**What this pass gives all future windows (the foundation):**
+- The **generic widget toolkit** — `UiButton`, `UiField`, `UiScrollbar`, `UiText`,
+  `UiMenu` — built automatically by `DatWidgetFactory` from the dat layout.
+- The **thin-controller pattern** — find-widget-by-id → bind-live-data — proven and
+  cemented on chat. Inventory's controller, vendor's controller, etc. all take the
+  same shape.
+
+**What those specific windows additionally need (out of scope here; cheap once the
+pattern exists):**
+- **A few more widget Types** — inventory/vendor lists want `UiListBox` (Type 5)
+  and `UiPanel` (Type 8); item slots want **drag-drop**, which retail builds into
+  `UIElement_Field` (the decomp shows `Field` has `CatchDroppedItem` /
+  `MouseOverTop` drag-drop hooks — so drag-drop rides on the Field widget this pass
+  already builds). Each gets *registered when that window needs it* — which is
+  exactly why §3 bounds "full registry" to the Types chat+vitals use today rather
+  than speculatively building all 14 retail classes.
+- **The window manager** — open/close/z-order/persist, drag-bars (Type 2),
+  resize-grips (Type 9). This is the *other* half of Plan 2 — a sibling piece to
+  this one — and lands alongside, because pop-up/stackable windows (inventory,
+  vendor) need it.
+- **Per-domain data plumbing** — item icons, live container contents, vendor stock
+  lists. Game-state work, separate from the UI toolkit.
+
+This pass is therefore the **reusable toolkit + assembly pattern** that makes those
+later windows mostly-free to build. It is the load-bearing first half of the road
+to inventory/vendor/spell-bar, not the whole road.
+
 ---
 
 ## 2. Retail reference (the registry + the PostInit pattern)