process-gap(test-writer+implementer): data-driven parameters applied at initial load only — runtime identity-switch path never re-applies, stale value persists silently

## Summary

Per-entity data-driven parameters were applied only inside the scene-lifecycle ready hook. A runtime identity-switch path (changing the active entity without reloading the scene) never re-applies the parameters, so after a switch the active entity silently retains the previous entity's parameter value.

## Detection gap

- The test suite contained multiple switch-path tests; every one asserted post-switch identity, signal state, and UI state. None asserted the data-driven parameter across the transition.
- Human playtests were insensitive to the stale value (it produced movement at a "normal-feeling" speed rather than a visibly broken one).
- The defect was caught only by an adversarial reviewer who derived expected travel distance from the data source files and cross-checked it against the attestation plan's frame arithmetic. The arithmetic required the correct per-entity value; the stale value produced a different frame count, which flagged as a mismatch.

## Pattern

Data-driven parameters bound to a switchable identity create a specific gap: tests authored against the ready-hook path are complete and correct, but the runtime switch path is untested because test-writers naturally model the initial-load scenario. The stale-parameter failure is structurally invisible to any test that does not explicitly assert the parameter value before and after the switch.

## Proposed remedies

1. **Test-writer guidance:** For any data-driven parameter bound to a switchable identity, the test suite must include a cross-transition re-verification test: assert the parameter's value, perform the switch, assert the parameter's new value matches the new entity's data-file entry (not the old entity's).

2. **Adversary lens — physical quantity derivation:** Attestation plan adversarial review should include a pass that derives physical quantities (distances, durations, speeds) from the data source files and checks that plan frame counts, timing windows, and range bounds are arithmetically consistent with those quantities for the specific entity being attested. Inconsistency implies either a stale parameter or a wrong plan constant.

3. **Implementer checklist:** Any code path that switches the active entity must explicitly re-apply all data-driven parameters. Checklist item: "for every data-driven parameter set in the ready hook, is there a corresponding re-apply call in every switch path?"

## Cross-references

- Related to #419 (spec-diff re-read) in that re-reading the data source before authoring attestation plans would surface the arithmetic inconsistency.
- Related to #479 (measuring-instrument end-to-end wiring) — both are cases where component-level tests pass while a wiring/re-application step is missing.
- Related to #480 (hand-seeded fixtures violating atomic-production invariants) — both involve test fixtures that exercise the nominal path while leaving the real-state path uncovered.