fix(ui): OP3 review fixes — byte-verified Magic chat lines, Gameplay/OptionPage shape, mid-air tri-state, shared geometry

Consolidated fix round for the two OP3 dual-lens reviews
(docs/research/2026-08-11-op3-review-{mechanism,blast}.md), both
APPROVE-WITH-FIXES.

MUST-FIX:
- The six "Use Mouse Turning Settings" chat lines were typed
  RetailLogTextType.ClientLocal (0x1A); retail types them 0x07 (Magic).
  BYTE-VERIFIED against the PDB-paired binary at all six
  gmConfigUI::SetMouseTurningDefaults call sites (0x0049E972/E9E2/EA52/
  EAA4/EAF6/EB48): every site pushes `6a 07` (type=7) immediately before
  the text-pointer push and the AddTextToScroll call. Added a dedicated
  OptionsRuntimeBindings.DisplayMouseTurningMacroLine seam routed at
  Magic (scrolling chat transcript, light blue, timestamped) instead of
  the 4-slot SpewBox ClientLocal uses; the mid-air refusal and UA/RA
  keep ClientLocal (both independently confirmed correct).
- Filed AD-77: the client-wide floating-only gmPanelUI host divergence
  (retail also exposes a docked 0x21000017 host) the plan §5 delegated
  to this review, scoped to every main panel, not just Options.

SHOULD-FIX:
- gmGameplayOptionsUI is not an OptionPage in retail (acclient.h:55857,
  UIElement_Field). OptionsPanelController now constructs the Gameplay
  slot's OptionPage with AfterApply deliberately null, so entering/
  leaving that tab never publishes SaveCharacterOptionsRuntimeCmd.
  Corrected OptionPageModel's doc comment and rewrote the two tests
  that pinned the wrong (Gameplay-flushes) shape.
- Added the OptionPage.OnOptionChanged seam (PlayerOptionPage::
  OnOptionChanged @0x004F27D0) — fires as the last step of Apply/
  Reset/Defaults, plus once per live LED edit via a new
  IOptionRow.AttachPageNotify hook (BoolOptionRow wires it into
  SetCurrentValue only, matching retail's Apply(1)-only
  HandleDialogAndNotices path). OP4-6 will bind Apply/Reset enable
  state to this.
- Exit to Character Selection's mid-air refusal is now tri-state
  (Func<bool?> IsGrounded): retail's UseTime only reaches the airborne
  test inside `else if (smartbox->player)`, so outside player mode (or
  with no live controller) the button is a SILENT no-op, not a
  refusal. Fixed the inverted comment at both call sites.
- Options panel geometry now matches its nine gmPanelUI siblings
  sharing RetailPanelUiController's one main-panel rectangle
  (ResizeX=false, bottom-edge-only resize, no invented Min/MaxWidth/
  Height) instead of being the only all-four-edge/horizontal-resize
  outlier whose width silently reverted whenever a sibling was shown.
- Added the three missing test pins: Options/Character mutual
  exclusion through a REAL RetailPanelUiController registration,
  RetailDialogFactory.MakeConfirmation's omitted-queueKey overload
  sharing DefaultQueueKey, and UiTabPanel.ActivePageChanged never
  firing on a dormant (non-activated) host.
- TS-74's What/Where now names the five store-only CameraTurning
  preferences explicitly instead of only mentioning them in Risk.
- Test script gains the toolbar-button ghosted->enabled+highlight
  check, UseMouseTurning-survives-relogin and the five prefs-survive-
  relaunch steps, a UA/RA legibility eye-item, and the corrected
  bottom-edge-only geometry description for step 5.

One-liners fixed in files already touched: symmetric close-button
resolve-failure logging in OptionsPanelController.Bind (blast NOTE 8).

Full Release suite: 12,947 passed / 4 skipped / 0 failed (baseline
12,935/4/0 post-OP7 — 12 net new tests; the two OptionPageModelTests
"wrong-shape" tests were renamed/rewritten in place, not removed).

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

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

@@ -81,6 +81,35 @@ public sealed class RetailDialogFactoryTests
         Assert.False(factory.IsOpen);
     }
 
+    /// <summary>
+    /// Blast review SHOULD-FIX 3 / NOTE 3 (2026-08-11 fix round): the Options
+    /// panel's Exit-to-Character-Selection confirmation goes through
+    /// <c>RetailUiRuntime.ShowConfirmation</c> -&gt; <c>MakeConfirmation(message,
+    /// callback)</c> with NO explicit <c>queueKey</c> argument. Nothing pinned
+    /// that the omitted-key overload actually shares
+    /// <see cref="RetailDialogFactory.DefaultQueueKey"/> with every other
+    /// confirmation in the codebase, rather than silently defaulting to a
+    /// DIFFERENT key that would let two confirmations sit active
+    /// simultaneously instead of queuing.
+    /// </summary>
+    [Fact]
+    public void MakeConfirmation_OmittedQueueKey_SharesDefaultQueueKey()
+    {
+        var root = new UiRoot { Width = 800f, Height = 600f };
+        var layouts = new List<ImportedLayout>();
+        var factory = CreateFactory(root, layouts);
+
+        factory.MakeConfirmation("uses the omitted-queueKey overload");
+        factory.MakeConfirmation("explicit DefaultQueueKey", queueKey: RetailDialogFactory.DefaultQueueKey);
+
+        // If the omitted-queueKey call had used a DIFFERENT key, both would
+        // be ACTIVE simultaneously (distinct queue groups run independently
+        // — QueueGroupsAndNonQueuedDialogsCanBeActiveTogether below) instead
+        // of the second queuing FIFO behind the first.
+        Assert.Equal(1, factory.ActiveCount);
+        Assert.Equal(1, factory.PendingCount);
+    }
+
     [Fact]
     public void QueueGroupsAndNonQueuedDialogsCanBeActiveTogether()
     {