Autoscaler behavior and state persistence during topology edits in Breakscale.

## Summary

Adding or removing an unrelated component can revert an autoscaler-controlled
node from its live scaled instance count to the older value in the React
topology. The autoscaler's internal target survives, so the controller and its
target can then disagree while the controller still reports `steady`.

This is separate from #30: the simulation clock and retained node state survive
the topology edit, but a controller-owned configuration field is overwritten.

## Deterministic reproduction

Using the `autoscaling-service` preset with seed 42:

1. Set the client to 1,000 RPS.
2. Advance for 30 simulated seconds. The API scales from its authored 3
instances to 5.
3. Call `setTopology` with the same topology plus one unconnected cache.
4. Snapshot immediately, without advancing the engine again.

The same harness produced this result on three consecutive runs:

```json
{
"configured": 3,
"scaled": 5,
"reset": 3,
"timeMs": 30000.000000000753,
"controllerBefore": {
"watchedInstances": 5,
"targetInstances": 5,
"scalePhase": "steady"
},
"controllerAfter": {
"watchedInstances": 3,
"targetInstances": 5,
"scalePhase": "steady"
}
}
```

The user's larger example shows the same symptom after adding a component:

![Autoscaler-controlled service falling back to one pod](files.carlulsoe.com/2026/08/9a0558ec4...

The screenshot URL is temporary and expires after 30 days.

## Exp...