Generalize background→UI session-state broadcasts (sign-out, account-switch, HW-unlock)

[JakeUrban]

Follow-up from #2082 (auto-lock UI flip).

Context

PR #2802 introduced a one-off SERVICE_TYPES.SESSION_LOCKED broadcast from background to UI so that idle auto-lock immediately flips all open extension UIs to the unlock screen. Internal review-fix round 1 noted that the same "background mutates session state, but other open UI surfaces stay stale until a pull-based refresh" pattern exists in several other paths:

• extension/src/background/messageListener/handlers/signOut.ts — sign-out only reaches the UI that initiated it.
• extension/src/background/messageListener/handlers/makeAccountActive.ts — active-account changes are returned to the caller only; other open windows (e.g. side panel + standalone signing window) can show a different active account.
• extension/src/background/messageListener/handlers/confirmPassword.ts — HW unlock updates background session only; sibling windows may stay locked/stale.

What needs to happen

Replace the ad-hoc SESSION_LOCKED broadcast with a small, typed session-event bus:

• Background helper broadcastSessionEvent({ type: "LOCKED" | "SIGNED_OUT" | "ACTIVE_ACCOUNT_CHANGED" | "UNLOCKED", payload? }) wrapping browser.runtime.sendMessage (with the existing no-receivers try/catch).
• A single popup-side SessionEventListener component subscribing to those events and dispatching the matching reducer (lockAccount, signOut, switchActiveAccount, refreshAccount).
• Migrate the lock path from Replace 24h absolute auto-lock with configurable idle timer #2802 onto this bus, and wire the three handler files above into it.

Add tests covering at least:

• sign-out from one open window locks/redirects sibling windows.
• account switch from one open window updates the active account in sibling windows.
• HW unlock updates sibling windows.

Dependencies

• Blocked by none, but should land after the stale-response guard (the other follow-up from Use idle-based timer for auto-lock behavior #2082) so that hook responses can't race against new broadcasts either.

References

• Parent issue: Use idle-based timer for auto-lock behavior #2082
• Implementation commits: b00599b, ecf489b (on plan-do-review/issue-2082 for PR Replace 24h absolute auto-lock with configurable idle timer #2802)
• Identified by: internal review-fix round 1 on PR Replace 24h absolute auto-lock with configurable idle timer #2802