feat(ui): improve mobile navigation and registry actions

docs/DESIGN_SYSTEM.md

@@ -61,6 +61,30 @@ Use the spacing tokens for new components. Prefer `8px`, `12px`, and `20px` gaps
 
 ## Layout patterns
 
+### Global mobile navigation
+
+At viewports up to 900px, replace the hidden desktop link rail and account
+controls with a clearly labeled square `MENU` control in the shared site
+header. Activating it opens a right-side SHD navigation panel over a dismissible
+backdrop. The panel includes Home, Discover, Builder, Guides, Sign In or My
+Profile, and ISAC when authorized; authenticated agents also receive identity
+state and Sign Out inside the panel.
+
+Use numbered full-width navigation rows, explicit active-route text styling,
+orange action indicators, and minimum 44px interaction targets. Opening moves
+keyboard focus to the first route. Escape, backdrop activation, route changes,
+and the header Close control dismiss the panel. The toggle exposes
+`aria-expanded` and `aria-controls`, the panel has a distinct navigation label,
+and reduced-motion preferences remove icon transitions. Do not make mobile
+users rely on the logo or desktop-only account controls to reach core routes.
+
+On phone-sized viewports up to 700px, ISAC module toolbars stack their action
+area beneath the module title. A single Add action spans the available width;
+multiple creation actions share an equal responsive grid. These controls use a
+minimum 48px height, centered labels, and the standard pressed, focus-visible,
+pending, and disabled treatments. Do not leave desktop-sized Add buttons
+squeezed beside long module headings on mobile.
+
 ### Public pages
 
 - Maximum content width: approximately 1400–1640px.
@@ -594,3 +618,18 @@ Inherent permissions that cannot be removed through role or user assignment use
 the compact blue information rail above the affected access controls. Always
 name the baseline and enumerate its capabilities so operators do not mistake an
 empty role assignment for an account with no effective access.
+
+### Mobile registry detail targets
+
+On narrow screens, a non-editing registry row with one canonical detail or
+review destination becomes a full-row tap target. Use a real stretched link
+when the destination is another route and a transparent button when it opens an
+in-page detail surface. Keep the explicit desktop `VIEW`, `REVIEW`, or
+`EVIDENCE` action, and add a visible mobile cue at the bottom of the row so the
+interaction is discoverable.
+
+The target must expose an accurate accessible name, show the standard orange
+focus-visible outline, provide pressed feedback, and meet a minimum 48-pixel
+tap height. Do not apply this pattern to edit, delete, approve, or other
+mutating actions, and do not stretch a target across rows containing independent
+interactive controls.