Measure a deviation against the base, not the innermost template

An instance edit was dropped as soon as its value matched the template
object. With nested containers the template is not what the value falls
back to: the outer container holds an edit for the object below it, and
that one wins. If the inner template happened to carry the same value the
user typed, the edit was thrown away and the value jumped to whatever the
container in between says.

Reported against the Jump-and-Run project: a coin narrowed to 8 inside
"level", then set back to the sprite's own 24 in the scene, snapped back
to 8. Reproduced through the inspector before touching anything.

InstanceTarget now offers `base`: the template with the edits of every
container in between woven in. Everything that judges deviation uses it -
setOverride/setName/setPosition, both Revert commands, and the gold marks
in the inspector. Writing still goes into the real template, which is
where "apply to container" belongs.

`base` is built on every read. Apply writes into the template and then
asks whether the edit still deviates, so a base captured beforehand would
answer for the template as it was - the e2e suite caught exactly that.

Also in here, because it corrects the commit before it: placing an asset
by double-clicking its row is gone, as asked for in asset-doppelklick.md.
Dragging is the only way to place now. That took AssetPanel.place, the
PlacementTarget interface, Editor.placementTarget and the two worldCenter()
methods that existed only to feed it. A double-click on a scene asset still
makes it the active scene.

todo-notes/done/asset-doppelklick.md

@@ -0,0 +1,18 @@
+Angeblich kann man Assets per Doppelklick in die Scene/Container platzieren. Das funktioniert aber nicht.
+Falls es irgendwie implementiert ist gehört es sowieso raus => Das Doppelklick Feature brauchen wir nicht!
+
+---
+
+**Umgesetzt (2026-09-09).** Raus, wie gewuenscht.
+
+Es *war* implementiert: `ListView` meldete einen Doppelklick (und Enter) als `onActivate`, und
+`AssetPanel.activate` platzierte damit in die Mitte der sichtbaren Ansicht — der Weg, den ich in
+`asset-drag-and-drop.md` noch als "bleibt bestehen" beschrieben hatte. Warum er bei dir nichts
+tat, habe ich nicht weiter verfolgt: das Feature faellt ohnehin weg.
+
+Entfernt sind damit auch die Teile, die nur dafuer existierten: `AssetPanel.place`, das
+`PlacementTarget`-Interface samt `Editor.placementTarget`, und die beiden `worldCenter()`-Methoden
+in `ContainerEditor` und `SceneViewport`, die sonst tot im Baum stehengeblieben waeren.
+
+**Geblieben:** Doppelklick (oder Enter) auf ein **Szenen**-Asset setzt es weiterhin als aktive
+Szene — das ist kein Platzieren, sondern derselbe Befehl wie im Kontextmenue.

todo-notes/done/asset-drag-and-drop.md

@@ -5,7 +5,8 @@ zukünftig soll es per drag and drop passieren
 
 **Umgesetzt (2026-09-09).** Drag and Drop ersetzt den Menueintrag vollstaendig — auf deine
 Ansage hin ist "Place in scene"/"Place in container" aus dem Kontextmenue verschwunden.
-Doppelklick auf die Zeile platziert weiterhin in die Mitte der sichtbaren Ansicht.
+Doppelklick auf die Zeile platzierte zunaechst weiterhin in die Mitte der Ansicht — auf deine Notiz
+`asset-doppelklick.md` hin ist auch das entfernt.
 
 - **Ziehen:** die Zeile im Assets-Panel wird nach 4 px Weg zum Drag; ein Ghost mit dem
   Asset-Namen haengt am Cursor (`src/ui/drag.ts`). Die `ListView` erkennt die Geste nur und

todo-notes/done/overwrite-reset-nested.md

@@ -0,0 +1,30 @@
+folgende fehlverhalten, beispiel jump and run projekt:
+- wenn ich IM container asset "level" von einem einzigen coin sprite die breite ändere von 24 => 8
+- wenn ich dann in der level scene bin und auf das geänderte coin sprite gehe und von 8 => 10 ändere funktioniert es noch
+- sobald ich aber auf den original standard wert 24 ändere (oder auf den reset button klicke) dann springt es zurück auf 8 (ist korrekt bei reset, aber wenn ich explizit die ursprünglichen 24 haben will, geht das nicht, weil dieser wert nicht mehr als overwrite gilt)
+
+---
+
+**Umgesetzt (2026-09-09).** Reproduziert im Browser am echten Jump-and-Run-Stand: nach dem Tippen
+von 24 stand `{"ov":8}` da, genau wie gemeldet. Deine Deutung war richtig — der Wert galt nicht
+mehr als Override und wurde weggeworfen.
+
+**Ursache.** Ein Instanz-Edit wurde geloescht, sobald der Wert dem Template-Objekt gleicht
+(`instanceRef.setOverride`). Bei **verschachtelten** Containern ist das Template aber nicht die
+Basis: `level` haelt auf seinem `c1`-Objekt einen Edit fuer das darunterliegende `coin-body`
+(die 8), und der gewinnt gegen das Template im `coin`-Asset. Traegt dieses Template zufaellig
+schon die 24 — was jede Ruecknahme auf den Asset-Wert in einem Container-Editor hinterlaesst,
+weil ein gespeicherter Override nie geloescht wird — dann galten 24 als "gleich dem Template",
+der Edit fiel weg und der Wert landete auf der Zwischenebene: **8**.
+
+**Fix.** `InstanceTarget` hat jetzt `base`: das Template mit den Edits **jedes Containers
+dazwischen** eingewoben. Nur das ist ein Wert, auf den etwas zurueckfallen kann. Alles, was eine
+Abweichung beurteilt, benutzt es: `setOverride`/`setName`/`setPosition`, die beiden
+`Revert…ToTemplate`-Kommandos und die Gold-Markierung im Inspector. Das **Schreiben** von
+"Apply to container" geht weiterhin ins echte Template — dort gehoert der Wert hin.
+
+Bei einer einzigen Ebene sind `base` und `template` identisch, das Verhalten aendert sich dort
+nicht. Reset landet weiterhin auf 8 (deine Erwartung), 24 bleibt jetzt als Override stehen.
+
+Drei Unit-Tests in `tests/core/apply.test.ts` halten es fest; zwei davon schlagen ohne den Fix
+fehl (gegengeprueft).

todo-notes/flaky-pixel-art-filter.md

@@ -0,0 +1,14 @@
+Der E2E-Check `pixel-art filtering keeps the border between two quadrants hard` faellt
+**sporadisch** um — heute (2026-09-09) zweimal in vier Laeufen, jeweils ohne dass eine Aenderung
+Texturen beruehrt haette.
+
+- gruen: `["#e63c3c","#e63c3c","#3cc85a","#3cc85a","#3cc85a"]` — harte Kante, `nearest` greift
+- rot:   `["#c65641","#a67047","#868a4c","#66a552","#3cc85a"]` — weicher Verlauf, also `linear`
+
+Der Folge-Check (`switching the filter back to smooth …`) meldet im Fehlerfall fuer **beide**
+Filter denselben Verlauf, ist aber trotzdem gruen — er vergleicht nicht gegen den Erwartungswert.
+Das heisst: wenn der Filterwechsel haengt, faellt genau ein Check, und der zweite deckt es zu.
+
+Zu klaeren: laedt der Test die Textur zu frueh aus (Timing), oder wird `scaleMode` beim ersten
+Setzen manchmal nicht auf die schon hochgeladene GPU-Textur durchgereicht (dann ist es ein echter
+Produktfehler und kein Testproblem)?

todo-notes/overwrite-reset-nested.md

@@ -1,4 +0,0 @@
-folgende fehlverhalten, beispiel jump and run projekt:
-- wenn ich IM container asset "level" von einem einzigen coin sprite die breite ändere von 24 => 8
-- wenn ich dann in der level scene bin und auf das geänderte coin sprite gehe und von 8 => 10 ändere funktioniert es noch
-- sobald ich aber auf den original standard wert 24 ändere (oder auf den reset button klicke) dann springt es zurück auf 8 (ist korrekt bei reset, aber wenn ich explizit die ursprünglichen 24 haben will, geht das nicht, weil dieser wert nicht mehr als overwrite gilt)

todo-notes/overwrite-textfarbe-auch-bei-assets.md

@@ -1 +1 @@
-die textfarbe beim asset soll auch in diesem gold dargestellt werden, falls ein property des assets einen override hat
+die textfarbe beim asset soll auch in diesem gold dargestellt werden, falls ein property des assets einen override hat