fix(ui): OP8 rework — activation/scope preservation, camera-row de-alias, conflict-confirm dialog

Fixes the three MUST-FIX findings from the 2026-08-11 combined dual-lens
review of commit b4edee97 (docs/research/2026-08-11-op8-review.md).

M1 — SetForAction destroyed ActivationType/InputScope on every write,
collapsing walk-mode's Hold, the three combat-scoped bindings, and
CameraInstantMouseLook's mouse chord the instant a row (including
Defaults, which touches all ~140 mapped rows at once) wrote back.
Widened the Bindings seam to carry the full Binding (chord + activation
+ scope), not a bare chord: KeyboardConfigController captures each
row's live Activation/Scope ONCE at build time (every multi-chord
action in KeyBindings.RetailDefaults() shares one pair across all its
bindings) and reapplies it on every write — rebind, Cancel/Revert, and
Defaults (which restores DAT-sourced KEYS only, never touches the
pair). New tests pin this across both Defaults and Cancel for a
Hold+MeleeCombat-scoped action.

M2 — InputMap 0x5 (CameraControls) and 0x6 (CameraAlternateControls)
aliased one InputAction each: both rows read/wrote the same live target,
so they showed identical stale chords, a rebind of one silently wiped
the other, and a row could conflict with its own twin. Building real
per-scheme dual-binding storage (or new InputAction members plus the
camera-dispatch code to consume them) is a feature, not a one-line fix.
Chose the third option: only ctx 0x5 — the scheme RetailDefaults()
actually has live support for — maps to InputAction; ctx 0x6 falls
through to the existing unmapped/store-only path (AP-203), fully
rendered, bindable, and persisted, honestly carrying no live effect.
This also retired 10 stale allowlist entries in the DAT-vs-
RetailDefaults() round-trip test: with the alias gone, ctx 0x5 alone
matches RetailDefaults() exactly for all twelve Camera actions.

M3 — the auto-reassign-on-conflict path was wired silent in production
(NotifyReassigned: _ => "") though the contract asked for a prompt and
retail confirms before overwriting (OpenOverwriteBindingDialog). Wired
a real confirm dialog through RetailDialogFactory.MakeConfirmation —
the same seam GameplayConfirmationController already uses — read
lazily since DialogFactory mounts after MountKeyboardConfig in
Initialize()'s order. Only reassigns on accept; decline leaves every
row untouched. AP-204 (which recorded the narrowing) is RETIRED; the
still-true OK/Cancel left-click-vs-right-click-release note moves to a
code comment (zero observable difference, doesn't warrant a register
row). Reverted the gate script's step 9 from documenting the silent
shape back to the real confirm-prompt behavior.

SHOULD-FIX addressed as one-liners in files already touched:
- S1: non-user-bindable conflicts are now checked BEFORE any row
  conflict (retail's own order), and ALL conflicting rows are collected
  (N-way), not just the first match.
- S3: Save wraps the file-write pair in the same try/catch
  RuntimeKeyBindingTarget.Apply already uses for keybinds.json.
- S4: assigning "Mapping 3" on a row with no existing bindings now
  lands on display index 2, not index 0 — ReplaceSlotValue trims only
  TRAILING empty slots instead of stripping every default(KeyChord).
  Right-click on an already-empty slot is now a no-op instead of
  shifting later bindings.
- S6: UiButton.OnRightClick returns false (unhandled, bubbles to
  parent) when no handler is set, disabled or not — matching the
  pre-existing behavior the class doc already claimed.

Left for a future pass (not one-liners): S2 (ActionMap.ConflictingMaps
is still unread — the conflict scan treats all 306 rows as one flat
universe instead of respecting the DAT's own legitimately-shared-key
table) and S5 (the ~330 DAT layout imports still run eagerly at mount
instead of lazily on first open).

19 KeyboardConfigControllerTests (was 12): +2 activation/scope
preservation (Defaults, Cancel), +1 camera de-alias, +2 confirm-dialog
accept/decline, +1 non-bindable-takes-priority-over-row-conflict, +1
sparse-row third-slot placement. Full solution suite 13,154 passed / 4
skipped / 0 failed (this round's baseline 13,147/4/0, zero regressions).

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

tests/AcDream.Core.Tests/Input/RetailActionIdentityRoundTripTests.cs

@@ -18,11 +18,18 @@ namespace AcDream.Core.Tests.Input;
 /// unavailable (CI), matching every other live-DAT conformance test in this project.
 ///
 /// <para>
-/// <b>Three real, byte-verified disagreements survive after the mechanism fixes</b>
-/// (2026-08-11 investigation — none are bugs in this slice's table; all three are
-/// PRE-EXISTING <see cref="KeyBindings.RetailDefaults"/> gaps/design choices this
-/// slice does not touch, listed in <see cref="KnownRetailDefaultsDisagreements"/>
-/// with citations):
+/// <b>Two real, byte-verified disagreements survive after the mechanism fixes</b>
+/// (2026-08-11 investigation, updated at the M2 rework — none are bugs in this
+/// slice's table; both are PRE-EXISTING <see cref="KeyBindings.RetailDefaults"/>
+/// gaps/design choices this slice does not touch, listed in
+/// <see cref="KnownRetailDefaultsDisagreements"/> with citations). A THIRD
+/// disagreement — ten CameraAlternateControls (InputMap 0x6) actions — was RETIRED
+/// at the M2 rework: <see cref="RetailActionIdentityTable"/> no longer maps InputMap
+/// 0x6 to any <see cref="InputAction"/> at all (the aliasing that produced two
+/// independent rows fighting over one live target — M2, 2026-08-11 review), so this
+/// test never sees a ctx-0x6 row and the ctx-0x5-only union now matches
+/// <c>RetailDefaults()</c> exactly for all twelve Camera actions with no allowlist
+/// entry needed:
 /// </para>
 /// <list type="number">
 /// <item><description><b>MovementWalkMode.</b> The DAT's raw <c>QualifiedControl.Modifier</c>
@@ -33,18 +40,6 @@ namespace AcDream.Core.Tests.Input;
 /// <c>CurrentModifiers=Shift</c> alongside a Shift key-DOWN event, so the chord must
 /// carry the flag to match at dispatch time. Not a disagreement to fix; a raw-DAT
 /// artifact this slice's reader faithfully reproduces.</description></item>
-/// <item><description><b>Ten CameraAlternateControls (InputMap 0x6) actions.</b> Retail
-/// ships TWO camera-control schemes with DIFFERENT default keys: InputMap 0x5's
-/// (Numpad: Keypad4/6/8/2 for rotate, KeypadSubtract/Add for zoom, ...) and InputMap
-/// 0x6's (Arrow keys: Left/Right/Up/Down for rotate, ...). Both InputMaps' actions
-/// share the SAME <see cref="RetailActionClass.Camera"/> bucket and this slice
-/// correctly maps BOTH to the same <see cref="InputAction"/> (research doc §5.3: a
-/// user can rebind either scheme's row independently). <c>RetailDefaults()</c> — a
-/// PRE-EXISTING, OP8-independent file — only carries the Numpad (0x5) scheme; it does
-/// not carry the arrow-key (0x6) alternates as SECOND bindings for the same action.
-/// This is a genuine <c>RetailDefaults()</c> completeness gap, reported here rather
-/// than silently patched into a foundational, heavily-tested file outside this
-/// slice's scope (register row filed).</description></item>
 /// <item><description><b>Quickslot 1-9's Ctrl+N chord (and its SelectQuickSlot_1-9
 /// counterpart).</b> The DAT's own default
 /// master map binds Ctrl+1..9 to the SAME action id as bare 1..9 ("Quickslot N" —
@@ -67,16 +62,6 @@ public sealed class RetailActionIdentityRoundTripTests
     private static readonly HashSet<InputAction> KnownRetailDefaultsDisagreements = new()
     {
         InputAction.MovementWalkMode,
-        InputAction.CameraMoveToward,
-        InputAction.CameraMoveAway,
-        InputAction.CameraRotateLeft,
-        InputAction.CameraRotateRight,
-        InputAction.CameraRotateUp,
-        InputAction.CameraRotateDown,
-        InputAction.CameraViewDefault,
-        InputAction.CameraViewFirstPerson,
-        InputAction.CameraViewLookDown,
-        InputAction.CameraViewMapMode,
         InputAction.UseQuickSlot_1,
         InputAction.UseQuickSlot_2,
         InputAction.UseQuickSlot_3,