fix(app): destructive-action confirm — focus trap + SharesPage Unpublish modal

[graydawnc]

What

Two renderer-side a11y/UX fixes from the post-launch audit.

useFocusTrap — Tab/Shift+Tab containment on destructive modals

aria-modal="true" on the confirm dialogs is a hint to assistive tech but doesn't actually contain keyboard focus — Tab/Shift+Tab could escape into the underlying page. On a destructive confirmation surface (Unpublish / Schedule deletion) this is a real footgun: the next Tab might land on a destructive control the user never saw.

New hook wires into both UnpublishConfirmModal and DeleteAccountConfirmModal:

• Initial focus lands on Cancel (safe default — pressing Enter immediately on open doesn't commit the action)
• Tab/Shift+Tab cycles inside the modal
• Focus restores to the previously-active element on close
• Focusable detection uses offsetWidth > 0 && offsetHeight > 0 (NOT offsetParent, which returns null for position: fixed overlays) AND guards against aria-hidden tab-stops

SharesPage Unpublish — confirm modal instead of single-click revoke

The Share popover's unpublish already routes through UnpublishConfirmModal. The Published-list Unpublish action did not — clicking the EyeOff icon on a row immediately fired spoolShare.revoke(). Inconsistent with the destructive-action discipline elsewhere in the app.

stateDiagram-v2
    [*] --> Idle
    Idle --> Confirming: click EyeOff on row A
    Confirming --> Idle: cancel / Esc / outside-click
    Confirming --> Revoking: confirm
    Revoking --> Idle: 200 + cache.markRevoked + refresh
    Revoking --> Confirming: error (inline + toast)

    state Confirming {
        [*] --> RowsLocked
        RowsLocked --> RowsLocked: other rows<br/>disabled (locked prop)
    }
    state Revoking {
        [*] --> ActiveRowBusy
        ActiveRowBusy --> ActiveRowBusy: spinner on row A<br/>others stay locked
    }

Loading

While a revoke is in flight, every row's Unpublish button is locked so clicking another row can't silently no-op (the row-level busy spinner shows on the active row; other rows show as disabled — the user gets unambiguous feedback that the system is busy).

Verification

• pnpm --filter @spool/app exec tsc --noEmit clean
• pnpm --filter @spool/app test → 433 unit pass (the 1 fail is the pre-existing sessionResume.test.ts:38 macOS path-slug flake, unrelated)

Risk

• Focus trap: changes initial focus + Tab cycling behaviour on the two confirm modals. No existing tests assert on focus.
• SharesPage Unpublish flow: replaces single-click revoke with confirm modal. The Published-list surface is gated by VITE_FEATURE_SHAREPUBLISH which CI doesn't set, so e2e doesn't exercise this path — covered by manual smoke.
• locked prop on PublishedRow is optional with default false; existing callers (none external) unaffected.

Submitted by @graydawnc.