CMSUI views should not redefine shared layout parts (breadcrumb, heading, …) per route — a "main template" for CMSUI

[mliebischer]

Problem

Every CMSUI route/view currently assembles its own page scaffold: breadcrumb, heading, container/<main> structure, toolbar plugs. Because there is no shared place for these parts, views either duplicate each other or drift apart. Concrete instances from the History route (#30/#120):

• The History view copied @plone/contents' inline Quanta breadcrumb (including the home icon) because the shared layout breadcrumb component does not use the Quanta styling and cmsui must not depend on contents. Every future CMSUI view faces the same choice: copy it again or look different.
• The Changes to "<title>" heading, the container width, and the <main id="main">/toolbar-Plug wiring follow the contents/controlpanel convention by hand — each new route re-implements the same structure and has to know the convention.
• The History row-actions menu uses the Quanta Menu, while @@contents has its own local ItemActionsPopover — same UI element, two implementations, visibly different styling and behavior (deliberately NOT copied a third time, tracked as a known deviation in Add History route (#30) #120).

Goal

CMSUI routes should only contribute what is actually view-specific (the table, the form, the diff, …) and get the recurring parts from one central place — analogous to Plone Classic's main_template (METAL macros: views fill slots, the template owns breadcrumb, title, structure). In Aurora terms this likely means a combination of:

• a shared CMSUI view scaffold (layout route or wrapper component) that owns breadcrumb, heading, container, and the standard toolbar plugs, and
• shared, Quanta-styled building blocks (breadcrumb, actions popover, status indicators — the latter already tracked in Configurable workflow state colors #128) hosted in a package both @plone/cmsui and @plone/contents may depend on.

Open questions

• Which package hosts the shared parts? (cmsui must not depend on contents; candidates: @plone/components, @plone/layout, or a new package.)
• Slot-based (the registry's slot system, like the public UI) or a plain wrapper component?
• Migration path: @@contents, the control panels, and the History view already exist with hand-built scaffolds; they should converge onto the shared one.

References

• [CMSUI] - History route #30 / Add History route (#30) #120 (History view: breadcrumb copy and the known deviations are documented in the PR/status comment)
• Configurable workflow state colors #128 (configurable workflow state colors — same consolidation pattern for one specific building block)
• Plone Classic main_template as the conceptual model