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/CharacterCreationUiControllerTests.cs

@@ -1904,18 +1904,21 @@ public sealed class CharacterCreationUiControllerTests
     /// <summary>
     /// GF-2: the composed description routes through the shared rich-text
     /// helper — header segments (palette index 1) render in a DIFFERENT
-    /// color than body segments (index 0), and each segment's own escape
-    /// sequence is normalized. The fixture's description element carries
-    /// no authored <c>FontColorPalette</c>, so this also exercises
-    /// <see cref="DatRichText.PaletteColor"/>'s fallback (green header /
-    /// white body).
+    /// color than body segments (index 0), and an authored line break
+    /// splits into stacked lines. The harness resolver models
+    /// <c>DatStringResolver</c>'s post-decode output (the DAT's literal
+    /// "\n" escape decodes AT THE SOURCE since the 2026-08-17 systemic
+    /// round), so the fixture feeds a REAL '\n'. The fixture's description
+    /// element carries no authored <c>FontColorPalette</c>, so this also
+    /// exercises <see cref="DatRichText.PaletteColor"/>'s fallback (green
+    /// header / white body).
     /// </summary>
     [Fact]
     public void HeritageDescription_ComposesGreenHeaderAndWhiteBodySegments()
     {
         using var environment = new EnvironmentHarness();
         environment.Runtime.ResolvedStrings["ID_CharGen_Heritage_StartingSkills_Header"] = "Trained Starting Skills:";
-        environment.Runtime.ResolvedStrings["ID_CharGen_Heritage_StartingSkills"] = "Line one\\nLine two";
+        environment.Runtime.ResolvedStrings["ID_CharGen_Heritage_StartingSkills"] = "Line one\nLine two";
         environment.Controller.Open();
         environment.Runtime.SelectHeritageDirect(AluvianId);
         BumpRevisionAndTick(environment);
@@ -1924,7 +1927,7 @@ public sealed class CharacterCreationUiControllerTests
         var lines = description.LinesProvider().ToList();
 
         Assert.Contains(lines, l => l.Text == "Trained Starting Skills:" && l.Color == new Vector4(0f, 1f, 0f, 1f));
-        // The literal "\n" escape in the body segment must become TWO
+        // The source-decoded line break in the body segment must become TWO
         // separate lines, not render as a literal backslash-n.
         Assert.Contains(lines, l => l.Text == "Line one" && l.Color == Vector4.One);
         Assert.Contains(lines, l => l.Text == "Line two" && l.Color == Vector4.One);