fix: release repeat views when the host disconnects

[AKnassa]

What this does

Fixes a list (repeat) that comes back wrong after its component is taken out of the page and put back — which is what happens on a route change, a tab switch, or any time the DOM is moved.

Why

When a component was removed from the page, repeat let go of its data but kept its rendered rows. So when the component came back, it reused those stale rows instead of rebuilding them.

Two things went wrong as a result:

• If the list data changed while the component was away, you got errors from bindings pointing at data that no longer existed.
• Every row in the list fired its "disconnected" lifecycle callback twice, and both times before the parent's "connected" callback — the kind of ordering bug that is nearly impossible to attribute to its cause.

What changed

• When a list is genuinely being torn down, its rows' DOM is now parked and restored on the way back, rather than left dangling. Element instances and their state survive a DOM move.
• A list that is simply being handed new data (the recycling path used by nested lists) is untouched, so the fast path stays fast.
• Notifications that arrive while a list is detached are now ignored, matching the guards that already exist on the other view behaviors.

How to see it

Run the fast-element test suite. templating/repeat-reconnect.pw.spec.ts is new: it removes a component containing a list, changes the data, puts it back, and asserts the rows are rebuilt rather than resurrected. Those tests fail on main.

Performance was measured, because this is a hot path. Every steady-state scenario — create, reuse, splice, and the nested-recycle case that a naive version of this fix would have wrecked — comes out at parity with main. The added cost lands only on disconnect and reconnect (roughly 0.2 ms for a 500-row list per full cycle), which is not a per-frame path, and it is the price of actually taking the DOM out while detached. In the scenario this issue describes, the fixed version is likely faster, since main currently resurrects rows and then tears them down again.

Note for reviewers

RepeatBehavior.unbind() now takes the controller, and views carry an internal isUnbinding flag. That flag is what distinguishes "this controller is going away" from "this view is being recycled with new data" — without it, teardown would rebuild every nested list's DOM on every recycled row, which would be a real regression.

Fixes #7144

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.