Keep objects through a Load scene with a switch (#165)

A Load scene destroyed every object of the old scene. A player, a HUD
or a music object had to be built again in each scene, with its state
pushed through shared variables. A top-level object with the new switch
Keep on scene load now travels into the next scene as the same entity,
with everything below it.

- The switch is a common property right under Enabled, off by default,
  on the asset and on a placed object. The inspector shows the row on
  top-level objects of a scene only, as answered in the issue.
- runtime/keptObjects.ts holds the rules as pure functions.
  keptEntities picks what travels, objectsToBring copies the stored
  objects as the run parents them, and bringObjects puts them into the
  next scene.
- World.instantiate takes a handed entity as it is instead of making
  one. The next syncToModel then writes the run's values into the
  scene.
- BehaviorSystem.release takes the running instances out before the
  old world is destroyed, and the next system adopts them. They hear
  no On destroy and no second On start, and their sounds play on.
- PhysicsSystem.resume gives a dynamic body the velocity and spin it
  had.
- Duplicates: the object brought along wins. The next scene does not
  build its own object with the same id, which is the way back into
  the scene the object came from.
- Decided here: the next scene does not build a top-level object of
  the same asset that is kept itself either. The issue only names the
  id. With the id alone a level that places its own player would hold
  two after a swap.
- Decided here: kept objects land behind the scene's own, the switch
  is no animation row, and collisions are found anew.

A finding, fixed along with it: Load scene did not build a scene as it
is stored, but as the run had left it. A moved object stayed moved and
a destroyed one stayed gone. The way back into a scene needs a clean
build.

- GameRun copies a scene's objects and groups before it first builds
  it and puts them back before it builds it again.
- GameRun.end puts every such scene back. The player calls it on stop,
  so spawned objects no longer stay for "Click to play again".
- The consequence: an edit made in a scene during Play is gone the
  next time that scene is loaded.

Tests:
- Gate: 199 files, 2944 tests (2929 + 15), exit 0
- e2e, full run: 1625 checks passed (1619 + 6), exit 0
- Smokes: 24 / 19 / 21, exit 0
- 15 unit tests in tests/core/keep-on-scene-load.test.ts
- Six e2e checks in module 35: the switch is set with a real mouse,
  the child has no row, the object is in the new scene, its counter
  still reads 1, its sound plays on, and the stored scenes are
  unchanged after Stop
- Eleven tests with fixed row lists only count the new schema row
- 16 unit counter-probes all fail tests, run on stein2. One did not
  fail at first (same id not left out), it has its own test now.
- The browser counter-probe fails 4 of the 6 new checks
- Not looked at in the browser: the switch as a port of the Properties
  node, and a released game with a kept object

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

tests/core/enabled.test.ts

@@ -38,7 +38,12 @@ function wallAndMover() {
 describe('the enabled switch', () => {
   it('is a common property of every placeable type, defaults to on and overrides per object', () => {
     expect(schemaFor('sprite')[0]).toMatchObject({ key: 'enabled', kind: 'boolean', default: true });
-    expect(schemaFor('behavior').map((d) => d.key)).toEqual(['enabled', 'runInEditor', 'runWhilePaused']);
+    expect(schemaFor('behavior').map((d) => d.key)).toEqual([
+      'enabled',
+      'keepOnSceneLoad',
+      'runInEditor',
+      'runWhilePaused',
+    ]);
     expect(schemaFor('scene').some((d) => d.key === 'enabled')).toBe(false);
 
     const f = makeSpriteScene();