Export behaelt die volle Aufloesung, Kontrolle erkennt fehlende Bilder

Der Export staucht nicht mehr auf 1080 x 1350. Die Slide entstand bei
Renderqualitaet k longst in 1080k x 1350k und wurde unmittelbar vor dem
Speichern wieder heruntergerechnet -- eine Vorlage mit 2390 px kam so mit
916 px an, obwohl sie bereits in 2748 px gerendert vorlag. Gespeichert wird
jetzt, was gerendert wurde; bei 3x sind das 3240 x 4050. Die Statuszeile
nennt die Groesse, und wer exakt 1080 will, stellt die Stufe auf 1x.

Die Kontrolle vor dem Speichern hat ihren Zweck verfehlt. Sie prueft, ob
jede Bildflaeche im Ergebnis Pixel traegt, sah dafuer aber das
achsenparallele Umrechteck an. Die Szenen-Displays stehen per matrix3d
schraeg im Raum, in ihrem Umrechteck liegen Rasterlinien, Hintergrund und
das Nachbargeraet -- deren Kontrast reichte immer, um durchzukommen. Eine
Slide mit voellig leerem Display wurde deshalb stumm gespeichert.

Jetzt werden die echten vier Ecken ausgemessen (ueber 1-px-Marken, Chrome
kennt getBoxQuads nicht) und nur die Ueberlappung von Bild und Rahmen
abgetastet. Beides einzeln fuehrt in die Irre: das Szenen-Display ist
groesser als der sichtbare Ausschnitt, das Feature-Mockup umgekehrt. Die
Geraeterahmen stehen neu mit auf der Liste, geprueft ueber den aus der
Vorlage geeichten Dunkelanteil. Nachgestellt mit opacity 0: vorher still
gespeichert, jetzt Abbruch mit Nennung der Flaeche. 11 von 11 echten
Ausfuhren laufen ohne Fehlalarm und ohne Wiederholung durch.

Die Szenen-Screenshots fuellen ihr Display randlos. Sie lagen als kleinere
Rechtecke an handgemessenen Prozentwerten darin, die nicht aus der
Glasflaeche des Mockups stammten: 656 px blieben rechts frei, 470 px unten,
und die Werkzeugleiste des Boards verschwand oben trotzdem unter der
Blende. Weil Prozentwerte in translate() an der Bildkante haengen, loesten
Vorschau und Export sie unterschiedlich auf -- die Luecke war im Export
groesser als im Canvas. object-fit uebernimmt das jetzt, es bleibt kein
Versatz, der auseinanderlaufen koennte.

Dazu behoben: post1-alt.html konnte vier Laptop-Layouts und Slide 2
ueberhaupt nicht exportieren. workflow.png haengt an keiner Slide mehr und
fehlte in der Ladeliste, im Bild stand src="undefined".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

rules.md

@@ -570,24 +570,30 @@ keine Scrollbalken oder Cursor-Reste im Bild.
 
 ## 7. Export & Bildqualität
 
-### Die zwei Regeln, aus denen alles folgt
+### Der Export behält die gerenderte Auflösung
 
-**1. Genau 1080 px breit hochladen.** Instagram behält bei Breiten von 320 bis
-1080 die Originalauflösung. Alles darüber wird **von Instagram selbst**
-verkleinert und danach neu komprimiert — Qualitätsverlust in zwei Runden statt
-einer. Ein 4000-px-Upload ist deshalb schlechter als ein 1080-px-Upload, nicht
-besser.
-
-**2. Trotzdem größer rendern.** Wir rastern intern bei **2×** (2160 × 2700) und
-skalieren selbst auf exakt 1080 × 1350 herunter. Das ist kein Widerspruch zu
-Regel 1, sondern der eigentliche Trick: Wir kontrollieren das Downsampling,
-statt es Instagram zu überlassen.
+**Gespeichert wird in 1080·k × 1350·k**, wobei k die Renderqualität ist. Bei 3×
+sind das 3240 × 4050. Die Datei ist damit so groß wie das, was tatsächlich
+gerendert wurde.
 
 ```
-2160 × 2700  →  Halbierung  →  1080 × 1350  →  Upload
-   render                        exakt
+Renderqualität 1×  →  1080 × 1350
+Renderqualität 2×  →  2160 × 2700
+Renderqualität 3×  →  3240 × 4050
 ```
 
+**Früher stand hier das Gegenteil**, und die Begründung war das Upload-Verhalten
+von Instagram: Breiten von 320 bis 1080 bleiben unangetastet, alles darüber wird
+von Instagram verkleinert und neu komprimiert, also lieber selbst sauber auf
+1080 herunterrechnen. Der Preis dafür war aber, dass jede gelieferte Aufnahme
+auf die Breite ihres Rahmens im 1080er Blatt eingedampft wurde — eine Vorlage
+mit 2390 px kam mit 916 px an, obwohl sie intern schon in 2748 px vorlag.
+
+**Das wiegt schwerer als der Upload-Pfad.** Wer eine hoch aufgelöste Aufnahme
+liefert, muss sie im Ergebnis wiederfinden. Kleiner rechnen kann jedes
+Zielsystem selbst, und wer bewusst exakt 1080 × 1350 will, stellt die
+Renderqualität auf 1×.
+
 ### Warum das Supersampling hier hilft
 
 Nicht wegen des Textes — den rastert der Browser bei nativer Größe ohnehin
@@ -605,20 +611,20 @@ sauber, teils sogar schärfer als supersampled. Der Gewinn liegt woanders:
 > ist die Stufe umschaltbar (1× / 2× / 3×), nicht fest verdrahtet. **2× ist der
 > Standard**, 3× kostet spürbar Zeit und Speicher bei kaum sichtbarem Gewinn.
 
-### Warum stufenweises Halbieren
+### Falls doch einmal verkleinert werden muss
 
-Browser skalieren Canvas standardmäßig schnell statt gut: Pixel werden direkt
-übernommen, Nachbarinformationen gehen verloren, das Ergebnis rauscht. Zwei
-Gegenmaßnahmen, beide nötig:
+Nicht in einem Sprung. Browser skalieren Canvas standardmäßig schnell statt gut:
+Pixel werden direkt übernommen, Nachbarinformationen gehen verloren, das
+Ergebnis rauscht. Zwei Gegenmaßnahmen, beide nötig:
 
 ```js
 ctx.imageSmoothingEnabled = true;
 ctx.imageSmoothingQuality = "high";   // Default ist "low"
 ```
 
-Und: **in Halbierungsschritten** verkleinern statt in einem Sprung. Ein direkter
-Sprung von 3240 auf 1080 überspringt Zwischenpixel; zweimal halbieren mittelt
-jeweils über 2 × 2 und kommt einer echten Flächenmittelung nahe.
+Und **in Halbierungsschritten** verkleinern. Ein direkter Sprung von 3240 auf
+1080 überspringt Zwischenpixel; zweimal halbieren mittelt jeweils über 2 × 2 und
+kommt einer echten Flächenmittelung nahe.
 
 `createImageBitmap()` mit `resizeQuality` wäre der elegantere Weg, ist aber in
 Browsern uneinheitlich umgesetzt — teils wird die Option ignoriert. `drawImage`