fix(ui): systemic escape normalization at the string source

The exit-world confirmation (ID_Client_EndCharacterSessionConfirm, table
0x23000001 key 0x0EB1C41D) rendered its literal two-character "\n" escapes
because escape decoding lived in individual consumers — Batch E centralized
it for authored captions only (DatWidgetFactory.ResolveAuthoredString), and
each new string surface had to remember its own copy. The installed DAT
carries the escape in 4,365 of 7,050 strings; per-consumer normalization
was structurally guaranteed to keep leaking.

Retail's placement is the SOURCE, not the widget: every public StringInfo
resolution ends in StringTableMetaLanguage::UnescapeString @ 0x0067BDC0
(StringInfo::InqString @ 0x0042E490, GetLiteralValue @ 0x0042CA50), the
write side escapes (SetLiteralValue @ 0x0042C980; AddVariable_String
@ 0x0042E6C0 for template variables), and widgets receive decoded text.
Ported exactly:

- NEW RetailStringEscapes: UnescapeString/EscapeString + the
  GetUnEscapedChar @ 0x0067B750 / GetEscapedChar @ 0x0067B6C0 tables
  (\n \t \r \q + the ten metalanguage self-escapes []!{}#\|^$,
  byte-verified against the PDB-paired 2013 binary at 0x3FE178;
  unrecognized pairs stay verbatim).
- DatStringResolver.Resolve/ResolveAll unescape at the source;
  ResolveTemplate escapes each variable on insert and unescapes the
  composed whole — retail's round trip, so variable content (player
  names) can never be corrupted by the final decode.
- RETIRED the consumer copies (double paths would corrupt an authored
  "\n" into a line break): DatWidgetFactory.NormalizeEscapes + BuildText's
  inline replace, RetailUiRuntime.NormalizeRetailNewlines + the
  OpenCaptureInstructions inline replace, DatRichText.Compose's replace,
  IndicatorDetailText.Shape's replace. ItemAppraisalTextLayout's replace
  stays — WIRE-domain (server strings never pass the DAT source; retail's
  ItemExamineUI::AddItemInfo @ 0x004AC050 appends wire text verbatim), now
  documented as such.
- Consumer CR-strips retired with them: the installed DATs contain ZERO
  real CR characters (sweep-measured) and UiText.WrapWords already drops
  strays.

Tests: RetailStringEscapes conformance (escape set, unknown pairs,
round trip), DatStringResolver source-decode pins (including the exact
user-reported exit-world text shape and a backslash-carrying variable),
the installed-DAT escape sweep (7,050 strings; every resolution must equal
the retail unescape of the raw entry; inventory printed), and the existing
caption/rich-text/live-DAT pins relocated to the source contract.

App 5550/3 (live-DAT), Runtime 1747/0, complete Release solution green
across all suites.

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

tests/AcDream.App.Tests/UI/Layout/DatWidgetFactoryTests.cs

@@ -1144,8 +1144,10 @@ public class DatWidgetFactoryTests
     }
 
     /// <summary>
-    /// 2026-08-13 social gate round 3: a MULTILINE authored string (literal
-    /// backslash-n escapes in the DAT) word-wraps each authored line to the
+    /// 2026-08-13 social gate round 3: a MULTILINE authored string (a real
+    /// '\n' — the DAT's literal backslash-n escape decodes at the string
+    /// source since the 2026-08-17 systemic round, so the resolver seam
+    /// hands this factory decoded text) word-wraps each authored line to the
     /// widget's live width — retail's GlyphList draw, the same wrap the
     /// confirmation dialog view uses. The fellowship empty-state was
     /// rendering its three authored lines as three clipped runs.
@@ -1165,7 +1167,7 @@ public class DatWidgetFactoryTests
         // Width=100 fits 12 characters per wrapped line.
         var text = Assert.IsType<UiText>(DatWidgetFactory.Create(
             info, NoTex, null,
-            stringResolve: _ => "one two three four five\\nsix"));
+            stringResolve: _ => "one two three four five\nsix"));
 
         var lines = text.LinesProvider!();
         Assert.True(lines.Count >= 3);