Problem
-------
Clicking "تأجيل" (Postpone) on the floating upcoming-meeting alert opened
the postpone modal, but the alert panel — pinned at z-[60] — covered most
of the modal. The user could not see or interact with the postpone
controls (presets, custom minutes, Confirm).
Root cause
----------
- artifacts/tx-os/src/components/executive-meetings/upcoming-meeting-alert.tsx
pins the floating panel at `z-[60]`.
- artifacts/tx-os/src/components/ui/dialog.tsx (the shared primitive)
uses `z-50` for both overlay and content.
- Result: the alert always wins the layering fight.
Fix
---
Scoped to this single flow (the task brief explicitly said NOT to bump
the global Dialog z-index, so other dialogs/toasts stay unaffected):
- While `postponeOpen` is true, the alert panel <div> gets the `hidden`
class (display:none) and `aria-hidden=true`. The modal then sits on a
clean stage — no overlap, no hit-test interference.
- When the modal closes (Apply, Back, Escape, overlay click), the panel
reappears automatically if the meeting is still inside the
upcoming-window.
Test coverage
-------------
- New Playwright case: opens the alert → opens postpone → asserts the
alert is hidden, the postpone panel + chip-10 are visible AND
clickable (proving they're not behind an overlay) → presses Escape →
asserts the alert returns. Passes in 10.8s.
- Re-ran all 5 existing Postpone-tagged tests against the patched
component — 5/5 pass (~37.9s).
Architect review
----------------
PASS. Confirmed: scope is non-leaky (only UpcomingMeetingAlert touched),
behavior is direction-agnostic (no RTL branch needed), no regression to
Done/Dismiss/Open Meetings/Reschedule/Cancel paths, accessibility
correct (display:none removes from a11y tree).
Deviations
----------
None. Implementation matches the task brief exactly.
riyadhafraa
cc26550f0c