Name binding mutation can interrupt later value propagation

[PSU3D0]

Summary

While building the C6 name-selector calibration in PR #203, a deferred Calamine workbook stopped propagating a later source-value edit through an already prepared formula chain after workbook/sheet name bindings were mutated.

Observed sequence

1. Load formulas through the deferred Calamine path.
2. Register workbook- and sheet-scoped names that point at formula outputs.
3. Prepare/evaluate the selected chain.
4. Edit the chain input and evaluate; outputs update correctly.
5. Move both name bindings with update_named_range and evaluate the rebound outputs; the binding change is visible and a retained target plan correctly returns PlanStale(Symbols).
6. Edit the same chain input again and call broad or target evaluation.
7. The rebound name outputs can retain the previous chain value instead of reflecting the new source value.

The behavior reproduced during harness development with more than one warm edit. Reordering the mutation did not make it suitable for a performance sample because the contract under test became ambiguous.

Expected

A binding mutation should stale revision-bound plans, but after explicit rebuild/evaluation, subsequent ordinary value edits must still propagate through the formula dependency graph and update the rebound name outputs.

Current C6 treatment

PR #203 deliberately performs all ordinary value edits first, then runs a separate post-warm name-binding probe. The probe verifies exact PlanStale(Symbols), rebuilds once, and checks rebound outputs. It intentionally performs no subsequent value edit and documents this limitation.

This issue is not fixed or hidden by the C6 harness and needs a focused semantic regression test across evaluate_all, evaluate_targets, retained plans, and SheetPort.