perf: Drop query cache entries lazily instead of searching on every removal

[spydon]

Description

Stacked on top of #3960, which it targets as its base branch.

This started as a question about whether strictMode still earns its place now that
ComponentList is a flat array, and the benchmark written to answer it turned up an
unrelated cost in the same code.

The measurement

benchmark/type_query_benchmark.dart measured a single "two registered queries" churn case,
which cannot separate the cost of having one more cache from the cost of having a cache that
matches most of the container, and it had no read-side measurement to weigh those costs
against. It now runs four churn variants (no caches, one cache, and a second cache matching
either 1 in 50 or 4 in 5 of the children) and a read suite comparing a cached query<T>()
against the whereType<T>() scan an unregistered type falls back to.

The read numbers say the caches are still clearly worth having on top of the flat array: a
cached query is 12x faster than the scan at 1000 children, and still 4x faster at the 16
children a query such as GestureHitboxes.hitboxes typically runs over. So the answer to the
original question is yes, strictMode still guards something real, and false remains the
right default.

The fix

The churn numbers showed something else. Adding a second cache that almost never matches was
free (1835 -> 1930 us), but adding one that matches four fifths of the container cost 3x
(1835 -> 5670 us). That is not the cost of having a cache: remove searched every matching
cache for the removed component with List.remove, a linear scan plus a shift, so a removal
was O(n) in the size of each cache it matched, while the removal from the backing array
itself is O(1).

This makes the caches follow what the backing array already does. A removal only marks the
caches it matches, and the entries of the removed components are dropped in a single pass
before anything reads, reorders or adds to the caches again. One pass covers any number of
removals, so a removal is O(1) regardless of how many types are registered or how much of the
container they match.

The one observable difference is for a caller that holds on to the Iterable returned by a
previous query<T>() call across a removal: it now keeps seeing the removed component until
the next compaction, where before it would have been mutated underneath the caller (throwing
ConcurrentModificationError if that caller was mid-iteration). Every fresh read compacts
first, so any new query<T>() or whereType<T>() call is always up to date.

Benchmark results

Full benchmark/main.dart, before and after, on the same machine (flutter test, JIT):

Benchmark	Before	After
Type-query churn (no registered queries, whereType scan)	2352 us	2240 us
Type-query churn (1 registered query, matches 1 in 5)	1952 us	1740 us
Type-query churn (2 registered queries, second matches 1 in 50)	1981 us	1864 us
Type-query churn (2 registered queries, second matches 4 in 5)	5427 us	2054 us
Type-query read (1000 children, whereType scan)	4656 us	4302 us
Type-query read (1000 children, cached query)	350 us	340 us
Type-query read (16 children, whereType scan)	110 us	86 us
Type-query read (16 children, cached query)	18 us	18 us

The remaining suites (traversal, lifecycle churn, priority changes, hit testing, collision
detection, render) are unchanged within run-to-run noise, as expected: nothing outside the
query caches changed.

Checklist

• I have followed the Contributor Guide when preparing my PR.
• I have updated/added tests for ALL new/updated/fixed functionality.
• I have updated/added relevant documentation in docs and added dartdoc comments with ///.
• [-] I have updated/added relevant examples in examples or docs.

Breaking Change?

• Yes, this PR is a breaking change.
• No, this PR is not a breaking change.

Related Issues