fix: guard binding updates against stale notifications after view unbind

[janechu]

Pull Request

📖 Description

When a parent when directive tears down and recreates a child custom element with a property binding (e.g., :data), the child's template bindings could evaluate with a null source, causing a crash. This occurred because the coupled source lifetime optimization in ExpressionNotifierImplementation left expression observers subscribed to the child element's observable properties after the child's view was unbound.

Added isBound guards to HTMLBindingDirective.handleChange() and RenderBehavior.handleChange() to skip binding re-evaluation when the controller's view is no longer active. This prevents stale notifications from reaching expressions that would crash with a null source.

🎫 Issues

• Fixes fix: when directive: child bindings may evaluate with no controller after teardown/recreate #7422

👩‍💻 Reviewer Notes

The root cause is that ExpressionNotifierImplementation.requiresUnbind() returns false for SourceLifetime.coupled bindings that only depend on the controller source. This means those observers are never disposed when the view is unbound, under the assumption that they will be garbage collected with the element. However, when a when directive reuses a cached view (same template), the element survives the unbind and the stale observers can fire.

The guards in handleChange() are a defensive fix at the subscriber level. A deeper fix would be to revisit the coupled lifetime optimization so that observers are always disposed on unbind for views that can be reused. That could be addressed as a follow-up.

The render test fixtures that used raw controller objects with isBound: false have been updated to set isBound = true after behavior.bind() to match real HTMLView lifecycle behavior.

📑 Test Plan

Two new Playwright tests added to binding.pw.spec.ts:

1. Crash regression test — Reproduces the exact issue fix: when directive: child bindings may evaluate with no controller after teardown/recreate #7422 scenario: creates parent/child elements, toggles the when condition through multiple cycles (on → off → on → data change → off → on), and verifies no crash occurs.

2. Rendering correctness test — Verifies that the child element's template correctly renders the pushed data label after toggling the when directive off and back on with new data.

All 1423 tests pass (1421 existing + 2 new).

✅ Checklist

General

• I have included a change request file using $ npm run change
• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

⏭ Next Steps

• Consider revisiting ExpressionNotifierImplementation.requiresUnbind() to properly dispose coupled-lifetime observers when the view is unbound, rather than relying on the subscriber-level guard. This would eliminate stale subscriptions entirely rather than silently skipping their notifications.

[janechu]

Converting to draft to consider a more holistic approach on disposal of coupled lifetime observers. This could create some performance issues either way (from notifications that are silently ignore or from re-creating observables).

[radium-v]

just commenting here to point out that this is the main change in the sea of comma linting adjustments.