feat(core): add layered side rail preferences

docs/PAGE_LAYOUT_USAGE_GUIDELINES.md

@@ -18,6 +18,30 @@ wording, authorization, consequences, and data state.
 - Do not reproduce shared page padding, heading, toolbar, form-grid, section,
   table, dialog, or breakpoint CSS in a module.
 
+## Product Side Rail
+
+Module manifests contribute stable navigation surface identifiers, labels,
+paths, icons, and default order. Core owns the side-rail composition and the
+shared `NavigationPreferenceEditor`; modules must not fork this editor or
+persist their own rail ordering.
+
+Navigation preferences are layered in this order: module defaults, system,
+tenant, then user. Each higher layer may reorder or change visibility. System
+and tenant administrators may lock an entry visible; a lower layer can still
+move that entry, but cannot hide it. Personal preferences cannot create locks.
+An unset preference inherits the complete lower layer, while “Use inherited
+order” removes the current layer rather than copying its values. Unknown item
+identifiers remain harmless so uninstalling, disabling, or later reinstalling
+a module does not corrupt the rail.
+
+The platform module response projects module, system, and tenant layer states
+alongside the effective user state. Editors must initialize from the layer
+immediately below the scope they edit, so a system or tenant administrator's
+personal preference is never promoted accidentally. Preference saves refresh
+the platform module projection. View policy, permissions, and tenant module
+entitlements remain independent final visibility gates; changing rail
+preferences never grants access.
+
 ## Semantic Page Archetypes
 
 | Archetype | Use when |