chore(webui): enforce semantic interface patterns

docs/architecture/INTERFACE_PATTERN_LANGUAGE.md

@@ -89,6 +89,17 @@ 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.
 
+`PageActionBar` is the semantic action contract for headed pages;
+`WorkspaceActionBar` applies the identical ordering and lifecycle rules to a
+full canvas and its collection, detail, and editor panes. Reload is always the
+leading action on a refreshable projection. Help and ordinary task actions
+follow contextual controls; Create is the far-right collection action;
+destructive actions occupy a named separated group; an editor ends with
+Discard and Save, with Save at the far right. Editor state is explicit:
+`clean`, `dirty`, `invalid`, `saving`, `save-failed`, or `conflict`. Lower-level
+`ActionToolbar` remains appropriate for a section-local view switch or compact
+control group, but it must not recreate page or pane action placement.
+
 Composite workspaces whose selected contribution supplies its own semantic
 heading may use `PageLayout` with its visible header delegated. This preserves
 the central inset, loading boundary, help identity, and content frame without
@@ -120,6 +131,10 @@ The current structural vocabulary is:
   distribution, density, grouping, panel/section surfaces, accessible toolbar
   naming, help identity, and responsive wrapping. Modules may add
   domain-specific presentation; they do not recreate the flex/wrap skeleton.
+- `PageActionBar` and `WorkspaceActionBar` own semantic ordering, Reload,
+  editor persistence state, destructive separation, and page/pane scope. A
+  module supplies action behavior, authority, blocker reasons, and wording;
+  it does not assemble another panel-header action convention.
 - `WorkspaceFrame` and `WorkspaceLayout` own application-viewport framing,
   surfaces, overflow, list/detail and navigation/content pane geometry,
   accessible region identity, and responsive pane behavior. Modules own only
@@ -144,8 +159,13 @@ The current structural vocabulary is:
   validation, permissions, or domain wording.
 - `MetricGrid` owns the responsive grouping around `MetricCard`: fixed one-to-five
   columns or auto-fit, minimum card width, density, surrounding rhythm, and a
-  named collapse point. Modules provide the metric, tone, and consequence;
-  they do not recreate the group grid or reach across module CSS to size it.
+  named collapse point. `MetricCard.drilldown` provides an explicit link or
+  in-page action when an authorized underlying detail helps the user act; it
+  names that destination and preserves the current scope and filters. The card
+  itself is never the hidden click target. Derived, privacy-suppressed,
+  non-enumerable, and purely informational aggregates remain inert. Modules
+  provide the metric, tone, destination, and consequence; they do not recreate
+  the group grid or reach across module CSS to size it.
 - `DescriptionList` and `DescriptionItem` own semantic property presentation.
   The stacked variant supports compact multi-column facts; the inline variant
   supports one-column term/value rows with a standard term width. Both own
@@ -230,7 +250,8 @@ one.
   names the object. Do not duplicate that action in a permanently visible side
   panel. A side panel used as the creation surface appears for creation and is
   otherwise absent or returns to its documented non-creation purpose.
-- Put filters beside the list or pane they affect. Put bulk actions immediately
+- Put filters beside the list or pane they affect. Put collection, detail, and
+  editor-pane actions in `WorkspaceActionBar` with the matching scope. Put bulk actions immediately
   above or beside the current selection. Put object actions with the object
   detail, not in the global title bar.
 - Full-page create and edit surfaces put their persistent action cluster in the