Say that deleting a template object clears references everywhere (#269)

- Behaviors: deleting an object in a container tab clears references
  to it in every scene and container, with a single undo.
- Containers: how the before/after comparison works and when a
  cleared instance edit falls back to the template.
- Development: e2e total 1607.

Behaviors.md

@@ -83,7 +83,14 @@ playing use the same two words.
   - **The reference follows the object:** removing it empties the reference in the same undo step,
     copying and pasting several objects points a reference among them at the copy (one out of them
     stays), *Create container* and *Unpack* carry it along.
-  - An object that is gone reads as `(null)`, and the row shows `(missing)`.
+  - **Removing an object from a container template** (#269) empties every reference to it as well,
+    in the same undo step: in the template, in each placement of the container in every scene and
+    every other container (nested ones included), and on objects outside a placement that name its
+    copy. The row then says `None`. A placement that now holds the same value as its template
+    follows the template again. If the template has no value of its own there, the placement keeps
+    `None` as its own value, as if picked by hand, and *Reset* hands it back to the template.
+  - An object that is gone reads as `(null)`, and the row shows `(missing)`. That is left for
+    references that were already dead before #269: they disappear the next time the row is set.
 
   During a run the object sits right in the value, and every way out of the run empties what a
   graph wrote there again (`core/graph/liveObjects.ts`, `withoutObjects`): the values the editor run

Containers.md

@@ -40,6 +40,15 @@ container in between.
 The other direction is therefore just as small: **Apply to container** writes the value into the
 template and drops the edit, **Reset to container** drops the edit alone.
 
+A removal reaches past the holder it happens in when something else names what goes (#269).
+`RemoveSceneObjectsCommand` takes what every holder shows before and after (`shownObjectIds`, the
+resolved ids) and empties each object reference that named an object shown before and gone after
+(`dropReferencesToGone` in `core/model/objectRefs.ts`). A reference is looked up from where it sits,
+with `referenceCandidates`, just as the running game does, so the same rule covers the template, a
+placement's edits in any scene or container, nested placements and full derived ids on objects
+outside. An emptied edit that now equals its base is dropped like any other. All of it goes through
+the command's `Recorder`, so one undo brings every reference back.
+
 Two places do spell the content out. **Unpack** does it on purpose — the objects become ordinary
 ones and stop following. And **play mode bakes** every placed container into stored objects, in
 the throwaway copy of the model, because a running behavior may destroy one of them and a resolved

Development.md

@@ -18,7 +18,7 @@ php tests/php/accounts.test.php                               # the API's accoun
                                                               #   has and the web server's container has not (SKIP there)
 php tests/php/snapshots.test.php                              # the snapshot store (#231), the same way
 php tests/php/releases.test.php                               # the release store (#266), the same way
-node tools/seed-e2e.mjs && node tools/e2e.mjs                 # 1606 editor checks, screenshots in /tmp/gm-e2e-*.png
+node tools/seed-e2e.mjs && node tools/e2e.mjs                 # 1607 editor checks, screenshots in /tmp/gm-e2e-*.png
 GM_STEPS=20 node tools/e2e.mjs                                # or 1-12, or 6,20 — a subset while working on one step
 ./e2e.sh start [GM_STEPS]                                     # the same run detached, see below
 ./e2e.sh status                                               # live progress, or the last run's result