chore: enforce shared workspace layouts

docs/architecture/INTERFACE_PATTERN_LANGUAGE.md

@@ -71,13 +71,20 @@ entity, permission, workflow state, endpoint, or policy decision. Reuse does
 not justify moving domain semantics into Core.
 
 `PageLayout` is the standard frame for headed workflow, dashboard,
-configuration, monitoring and explanatory pages. It owns the scroll viewport,
-content inset, sticky responsive header, title and description geometry,
-route-action placement, transient page notices, loading boundary and page help
-identity. `PageHeader` is the escape hatch for full-canvas archetypes that need
-the same header contract but must own their workspace scroll. Specialized
-layouts such as `AdminPageLayout` compose these lower-level Core contracts;
-they do not repeat their markup or responsive CSS.
+configuration, monitoring and explanatory pages. It owns the content inset,
+sticky responsive header, title and rich-description geometry, route-action
+placement, transient and custom notices, loading boundary and page help
+identity. Its modes make scroll ownership explicit: `standalone` owns a page
+viewport, `workspace` defers scrolling to a full-canvas content pane while
+retaining the standard inset, and `embedded` owns neither scroll nor inset.
+
+`WorkspaceLayout` is the standard full-canvas shell. Its `navigation` variant
+owns module/resource subnavigation plus content; its `split` variant owns
+collection/detail panes. It centralizes pane sizing, internal scroll,
+responsive collapse/stacking, accessible pane labels and workspace help
+identity. `PageHeader` remains available when an exceptional canvas needs only
+the shared heading. Specialized layouts such as `AdminPageLayout` compose
+these lower-level Core contracts; they do not repeat markup or responsive CSS.
 
 Module CSS may arrange domain content inside a shared layout. It must not
 override Core layout internals or copy the outer page, dialog, toolbar, form or
@@ -95,10 +102,10 @@ Migration is incremental and enforceable:
 5. promote the next repeated structure only after its variants and extension
    points are understood.
 
-The intended next structural contracts are workspace/split-pane layout,
-responsive page toolbar, content grid, form-section layout, dialog body/footer
-layout and shared empty/error state composition. Their APIs must remain
-composable; a central component is not a single oversized page template.
+The intended next structural contracts are responsive page toolbar, content
+grid, form-section layout, dialog body/footer layout and shared empty/error
+state composition. Their APIs must remain composable; a central component is
+not a single oversized page template.
 
 ## Surface Archetypes