feat(composer): der Canvas — dieselben Komponenten, dasselbe Stylesheet

[BechsteinDigital]

1. Why is this change necessary?

Der Canvas soll die Vorschau sein, nicht eine haben (§7.6). Eine Vorschau, die aus einer
eigenen Annäherung an das Ergebnis gebaut ist, driftet — und die Drift fällt erst auf, wenn jemand
veröffentlicht hat.

Setzt die beiden verbliebenen Bedingungen aus §7.6 um: Theme-Tokens und Sektions-CSS in den Canvas
scopen.

2. What does this change do, exactly?

Er baut den Kompositions-Renderer nicht nach. Jener erzeugt Inseln — Platzhalter, die der
Browser später mit Vue-Komponenten füllt. Im Canvas liegen die Komponenten schon vor, also rendert
er sie direkt: dieselben Komponenten, ein Schritt weniger.

Das Insel-Markup nachzubauen gäbe dem Editor einen zweiten Renderpfad, und ein zweiter Pfad
ist einer, der driftet. So kann sich zwischen Canvas und Live nur die Daten unterscheiden — und
dieser Unterschied ist gewollt (simulierte Kontextwerte).

Er lädt das echte Stylesheet, eingesperrt. @scope statt Selektor-Umschreiben: das Konstrukt,
das die CSS-Arbeitsgruppe für genau diesen Fall gebaut hat. Ein Umschreiber, der einen Selektor
falsch behandelt, ist eine Vorschau, die lügt.

Zwei Dinge müssen eingesperrt werden:

• Die Regeln der Fläche würden sonst die Admin-Shell um den Canvas herum gestalten —
  .cal-header bedeutet auf beiden Seiten etwas.
• Die Theme-Tokens sitzen absichtlich auf :root. Das ist richtig für eine Fläche; im Admin gehört
  :root der Shell, und ein Workspace-Theme, das die Shell umfärbt, wäre absurd.

:root, html und body werden deshalb auf die Scope-Wurzel umgeschrieben: :root IST das
Dokumentelement und liegt außerhalb jedes @scope — ein Token-Block dort entkäme, ohne dass es
jemand merkt, bis die Shell plötzlich anders aussieht.

Ein verwaister Block bleibt im Editor sichtbar und benannt stehen. Das Frontend lässt ihn weg;
wer hier gestaltet, muss sehen, dass da etwas ist, das zurückkommt, sobald das Plugin wieder da
ist.

3. Describe each step to reproduce the issue or behaviour.

Zehn Tests für das Scoping, darunter die Fälle, die still schiefgehen:

Fall	Warum er zählt
:root nach einer anderen Regel	Ein Muster, das nur den Zeilenanfang prüft, übersieht ihn
Eine Klasse, die zufällig body enthält	.page-body darf nicht umgeschrieben werden
Zweites Stylesheet beim Theme-Wechsel	Muss ersetzen, nicht überlagern — sonst hängt das Ergebnis an der Einfügereihenfolge

Das Bundle wurde gebaut und referenziert CalloraVue — das eine Vue-Global aus #174, ohne das ein
Surface-Block im Admin-Canvas nicht laufen könnte.

4. Please link to the relevant issues (if any).

Setzt §7.6 Bedingungen 2 und 3 um. Baut auf #174 (ein Vue-Global) und #186 (Admin-API) auf.

Zahlen

13 Dateien. .NET 1980 + 29 Analyzer, Composer-UI 10 Tests — alle grün.

Noch nicht drin

• Drag & Drop und das generierte Konfigurationspanel.
• Das Laden der Surface-Plugin-Bundles in den Admin-Kontext. Der Canvas liest die
  Block-Registry aus window.calloraSurface; im Admin füllt sie bislang niemand. Das ist der
  nächste Schritt und der letzte, bevor der Canvas echte Blöcke zeigt.
• Der Klick-Konflikt (§7.6): ein Edit-Layer, der Pointer-Events auf Blockebene abfängt, mit
  einem „Interaktiv testen"-Umschalter.