ux(settings): override modal silently swaps account context when reopened

[cristim]

Summary

The override-create modal landed in #106 carries an overrideModalContext = { accountId, provider, panel } object. If the user opens the modal for Account A's overrides panel, then clicks the "Service overrides" button on a different account row (Account B) without first dismissing the modal, the loadOverridesPanel(accountId, panel, provider) flow on Account B's expansion will:

1. Render Account B's overrides into Account B's panel.
2. Auto-open the override modal for Account B (per feat(settings): create-override modal for AWS account overrides (closes #104) #106's empty-state path) — but the modal is already visible. modal.classList.remove('hidden') is a no-op when already not-hidden, so visually nothing flickers.
3. Overwrite overrideModalContext to Account B's coordinates.

From the user's perspective, the modal silently switched contexts. The form still shows whatever values they were typing for Account A, but a Save now creates the override on Account B. There's no visual indicator that the context changed.

It's not destructive (the user explicitly clicked the second account's expander), but it's confusing and unexpected.

Fix direction

Pick one:

A. Block the swap. When opening the modal, if overrideModalContext is already set and accountId !== overrideModalContext.accountId, ignore the new open or surface a confirm "You have an override in progress for {Account A}. Discard and switch to {Account B}?".

B. Show the swap clearly. Add the account's name + external_id to the modal's title (currently just "Add service override"). When context swaps, the title updates so the user sees "Add service override for AzureProd (sub-x)". Combined with a brief flash/highlight on the title when the context changes, the swap becomes visible.

C. Auto-close on outside click and force re-open. Before a different account's panel auto-opens its modal, close the existing modal (with a "Discard form?" if any field is dirty). Cleaner than B but more interruption.

Recommendation: B is the smallest change and gives the user the information they need without blocking. If user feedback shows it's still confusing, escalate to A or C.

Acceptance criteria

• Modal title shows the target account's name + external_id (e.g., "Add service override for Prod (111111111111)").
• Context swap during an open modal updates the title before any subsequent Save lands on the new account.
• Tests in settings-accounts.test.ts cover the title-changes path when modal-open is invoked twice for different accounts back-to-back.

Out of scope

• Confirm-on-discard for unsaved form input (dirty-tracking pattern). If user feedback drives it, file separately.
• The same context-swap pattern in other modals (account-modal — same gap exists when clicking edit on a different account while the existing edit is open; covered by a11y issue if needed).

[cristim]

We now have a per-account override modal instead of the expansion in the main UI