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>

docs/research/2026-08-11-campaign-op-test-script.md

@@ -910,13 +910,16 @@ line calling it INERT no longer applies.
 8. **Still on Movement, click "Move Backward"'s first key button**
    (currently "X"), then press **W** — the SAME key you just confirmed
    is bound to "Move Forward."
-9. **Expect**: "Move Backward" takes W, and "Move Forward" silently
-   loses its W slot (down to just "U" from step 5) — the SAME outcome
-   you'd get after confirming retail's own "reassign?" dialog, except
-   this port applies it immediately without asking first (AP-204,
-   register row — a deliberate scope narrowing for this slice; retail
-   shows a confirm dialog before reassigning). No error, no crash, both
-   rows' key-button labels update to reflect the swap.
+9. **Expect**: a confirmation dialog opens (retail's own
+   `OpenOverwriteBindingDialog`, ported through the same
+   `RetailDialogFactory` confirm mechanism the game's other Yes/No
+   prompts already use) naming "Move Forward" as the row that currently
+   holds the key and asking whether to reassign it to "Move Backward."
+   **Click Yes**: "Move Backward" takes W, and "Move Forward" loses its
+   W slot (down to just "U" from step 5); both rows' key-button labels
+   update to reflect the swap. Repeat steps 8-9 once more but **click
+   No** this time: neither row should change at all — the capture is
+   simply abandoned, exactly like Escape.
 
 ### Non-bindable refusal
 
@@ -989,9 +992,9 @@ line calling it INERT no longer applies.
   explicitly guards against — a regression here would mean one page's
   rows leaked into another, or the six reused element ids resolved to
   the wrong page's instance).
-- Whether the silent auto-reassign (step 9) or the refusal message's
-  odd phrasing (step 10) feels wrong enough in practice to warrant
-  building the real confirm-dialog integration AP-204 defers.
+- Whether the confirm dialog's wording (step 9) or the refusal
+  message's odd phrasing (step 10, the literal DAT string) reads
+  awkwardly enough in practice to warrant a follow-up polish pass.
 - Any row whose Emote/CharacterSettings binding visibly DOES something
   in-game despite AP-203 saying it shouldn't (would mean acdream grew a
   consumer for it since this table was written, and the identity table