Isolate mutable state when restoring the same checkpoint more than once

## Reproduced on current main9e4173f

Loading the same checkpoint dictionary into two independent standard Simulations can make them share mutable restored data:

1. Add an A-only pending memory after both restores; B.update() commits that memory too. Reproduces when updating existing entities and when building new entities from the checkpoint.
2. Mutating a nested raw-log entry in the input dictionary changes restored logs; subsequent writes in one restore can reach the other.
3. Prefab parameter fallback inserts missing keys into the caller-supplied checkpoint dictionary.

These are ownership bugs, not evidence about continuation scheduling. Canonical make_checkpoint_data, real minimal actors/standardGM and public memory APIs reproduce the memory case with no simulation/model calls.

## Proposed bounded correction

Take one independent deep copy of checkpoint data at the load_from_checkpoint boundary before component setters or fallback logic can retain/mutate it. Reuse the existing copy module and loader; no new serializer, engine or restore manager. Retain measurement fallback and intra-simulation GM wiring.

## Limits and prior work

This does not make restoration atomic, restore engine cursors/RNG/hosted models, validate arbitrary component compatibility, or establish controlled counterfactuals. Existing structured-observability proposal#275 is broader; contest-reproduction PR265 changes different files. Keep those concerns separate from reproducible input aliasing.

Start at the load_from_checkpoint boundary and trace the existing copy module and loader before component setters or prefab fallback logic run. Reproduce with canonical make_checkpoint_data, two standard Simulations, and the public memory APIs. Done means repeated restores do not share mutable memory or logs, do not mutate the caller's checkpoint dictionary, and retain measurement fallback and intra-simulation GM wiring.

Written by the indexing model from the issue text.