Add user notification inbox and delivery controls

docs/DESIGN_SYSTEM.md

@@ -659,3 +659,79 @@ the default SHD portrait. A stale review must never act on a newer upload.
 Historical entries retain metadata and audit evidence even when their image is
 no longer available. At narrow widths cards become one column, retain a large
 portrait preview, and expose a minimum 44-pixel review action.
+
+### Notification network
+
+Authenticated navigation exposes a compact inbox glyph with a numeric unread
+badge; mobile navigation provides the same explicit `INBOX` destination and
+count. Notifications live under the agent-profile namespace and use an explicit
+profile context trail back to account controls. The inbox is a dense
+communication registry with a source rail, category,
+title, timestamp, body, destination, and textual read state. Unread messages use
+the orange action rail. Mandatory ISAC notices use the blue operational rail and
+must always remain visible in the in-app inbox.
+
+Preferences are channel-by-category rather than global. Each category controls
+in-app, browser, and email delivery independently. ISAC in-app delivery is
+locked on, while its browser and email channels remain optional. Email defaults
+to off and offers `OFF`, `IMMEDIATE`, and `DAILY DIGEST`; browser delivery must
+follow an explicit browser permission gesture. Never imply background push when
+only active-site browser polling is available. At narrow widths preference rows
+stack their identity above channel controls and notification entries collapse
+their source rail above the message.
+
+The main Agent Profile surfaces the five most recent enabled inbox messages
+before authored-content modules and includes unread count as a profile metric.
+This preview preserves mandatory, unread, source, and category states, uses
+single-line truncation at desktop density, and links to either the notification
+destination or full profile inbox. On mobile, metadata becomes its own row and
+message body copy may wrap.
+
+Inbox messages use sender identity and semantic tone. ISAC sources use the SHD
+system mark, blue system labeling, and an explicit `SYSTEM` descriptor;
+community activity uses an agent portrait and `AGENT` descriptor. Positive
+outcomes use green, adverse or corrective outcomes use red, and informational
+content stays neutral. Message titles and body copy state the actual outcome;
+do not expose internal sentiment labels such as `POSITIVE`, `NEGATIVE`, or
+`NEUTRAL`. Reserve visible badges for operationally meaningful severity such as
+`WARNING` or `ERROR`, while the message wording remains understandable without
+depending on color alone.
+
+The inbox command header pairs the page identity with a compact bordered unread
+summary and a same-height preferences action. Filter selects and adjacent
+actions share a 40-pixel control height and vertically centered labels. Within
+each message, the tone/title/timestamp header uses modest vertical padding and a
+subtle lower rule: keep it dense, but never collapse it into a text-height strip.
+On mobile the unread summary and preferences action share one grid row, while
+filter controls stack into full-width, minimum 44-pixel targets.
+
+Page hierarchy uses the shared eyebrow breadcrumb rather than a separate
+breadcrumb row above a command header. It retains the short orange rule, renders
+ancestors as orange links, separates levels with a muted slash, and marks the
+final item as the current page. A top-level page may use a single current item.
+Do not duplicate the same hierarchy in both an eyebrow and a second contextual
+navigation strip; this creates visual overlap and wastes vertical space. The
+breadcrumb always uses intrinsic height and must not inherit the full-height
+primary-navigation treatment. Likewise, in-page command and message headings
+must use their named component classes rather than the global application
+`header` element treatment.
+
+`VIEW DETAILS` opens the standard in-page modal rather than navigating
+immediately. The modal repeats sender, source, category, semantic tone, time,
+full message body, read control, and optional related-page destination. This
+keeps review context in the inbox and makes outbound navigation deliberate.
+
+ISAC message content uses the structured system-transmission body. A compact
+blue `ISAC TRANSMISSION` kicker precedes the summary, and recognized supporting
+fields such as `OVERSIGHT REASON`, `REQUIRED ACTION`, or `DETAILS` become a
+labeled detail row beneath a subtle divider. The expanded message view uses the
+same hierarchy at reading size. Community messages remain conversational body
+copy; do not apply the system-transmission frame to agent comments.
+
+Inbox entries expose two distinct actions. `VIEW DETAILS` opens the complete
+message when preview copy is truncated to two lines. A separate bordered orange
+response action navigates directly to the known workflow and uses specific
+language such as `UPLOAD NEW AVATAR`, `REVISE CONTRIBUTION`, or
+`VIEW BUILD & REPLY`; never substitute a generic destination label when the
+notification type is known. The same response label appears in the detail
+modal. On mobile, response actions become full-width 44-pixel targets.