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/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).