feat(ui): add global feedback and agent menu

docs/DESIGN_SYSTEM.md

@@ -95,6 +95,25 @@ cards collapse from four columns to two and then one; hover color alone never
 replaces their textual destination labels, focus-visible treatment, or pressed
 feedback.
 
+Authenticated desktop account destinations are consolidated into one
+agent-status menu at the right edge of the global header. Its trigger combines
+the agent avatar, display name, online state, unread count, and an explicit
+expanded marker. The menu contains My Profile, Notifications, and Sign Out;
+these actions are not duplicated as standalone desktop header links. The menu
+uses the same square, compact control-surface treatment as the rest of the
+header, with orange reserved for the open/current state and unread count and
+danger color reserved for the Sign Out hover state.
+
+The account trigger exposes its expanded and controlled-menu state. Opening the
+menu moves keyboard focus to its first destination; Escape closes it and
+returns focus to the trigger, while an outside click dismisses it. Mobile keeps
+Profile, Notifications, and Sign Out as explicit navigation actions and shows
+the avatar in the signed-in identity block. Avatar imagery supplements rather
+than replaces the textual identity, state, and unread indicators. User avatars
+are always rendered as circular portraits with the restrained orange SHD ring
+used by the Agent Profile; the source image remains square and uses
+`object-fit: cover` so authenticated surfaces crop it consistently.
+
 Contact notifications use the mandatory ISAC visual identity because they are
 operational inbound messages. The notification carries a concise preview and a
 specific action to an authorization-checked full record. Full messages never
@@ -1392,3 +1411,34 @@ Weapon 1 · Top, and Weapon 2 · Bottom. Always include the Top/Bottom context
 when presenting numbered Weapon Talent slots to users. The filter remains
 additive within the group and wraps to two columns on narrow screens; do not
 introduce search or dropdown controls for this four-option set.
+
+Notification delivery preferences are a temporary profile control surface.
+After a successful save, close the interface and return focus to the inbox
+context. Consume a unique server result token only once so later actions or
+reopening the panel do not close it again. Validation and server errors keep
+the interface open with the submitted controls available for correction.
+
+### Global toast feedback
+
+Use the root-mounted `ToastViewport` and the shared API in `src/lib/toast.ts`
+for transient action feedback. Enhanced server mutations should normally use
+`PendingForm`, which derives success and failure feedback from the action
+result. Client-only operations call `toast.success`, `toast.error`,
+`toast.warning`, or `toast.info` directly. Do not create page-specific toast
+implementations.
+
+Toasts occupy the top-right safe area below the global header and show no more
+than four messages. Each uses a textual state label, tone-colored top and left
+rails, a concise title, optional supporting text, and an explicit dismiss
+control. Success is green, errors use danger red, warnings use SHD orange, and
+informational feedback uses restrained blue-gray. Color never carries state
+alone.
+
+Use success to confirm completed mutations, error for failed requests, warning
+when attention is required, and info for neutral client or system state. Keep
+inline validation beside affected fields even when an error toast is also
+emitted. Avoid toasts for passive navigation, filtering, hover, unpersisted
+selection changes, and background refreshes. Toasts automatically dismiss
+according to severity, remain keyboard dismissible, use `status` or `alert`
+semantics, and disable entrance motion with reduced motion. On mobile they span
+the safe viewport width below the header without obscuring navigation.