Walk the tree once per form.elements read instead of re-running a LINQ query - #1350

HtmlFormControlsCollection held one deferred LINQ query and re-executed it on every member:

_elements = root.GetNodes<HtmlFormControlElement>().Where(m => { ... m.Form ... });
...
public Int32 Length => _elements.Count();
public HtmlFormControlElement this[Int32 index] => _elements.GetItemByIndex(index);

So form.elements.length was a whole-document NodeEnumerable walk — a Stack<EnumerationFrame>, an
OfType iterator, a Where iterator and a closure — and form.elements[i] was another one. A loop over
length and [i], which is what a page does, paid all of it twice per iteration.

This keeps only the root to walk and the form to match against, and drives all four members — the length,
the indexed read, the named read and enumeration — through one struct walker and one predicate. The
collection stays exactly as live as it was: nothing is memoized, no result is materialized, every read
still queries the tree as it is at that moment.

The walker is the technique already in ElementTreeEnumerator — parent links plus a stack of child
indices, so the stack holds value types and is bounded by the tree's depth rather than its width — with
the index stack rented from ArrayPool<Int32>, which is what takes a read to zero allocations.

Why not reuse ElementTreeEnumerator itself, since it is most of this: it yields its root (and a
<fieldset> is itself a form control, so it must not appear in its own collection), its element is
untyped and unfiltered, and it allocates its index stack with new Int32[16] per walk. Composing on it
would have been about a third of the code and left one array per read. Making it pooled would have
fixed QuerySelector/QuerySelectorAll too, but it would push a disposal contract into the selector
engine, where a missed or doubled Dispose hands one buffer to two walkers and corrupts both silently.
That is not a drive-by change, so it is not in this one.

Semantics

Unchanged, and the equivalences are worth stating because they are what a reviewer would otherwise have
to re-derive:

• NodeEnumerable yields descendants only, never the starting node, which is what the new walker
  does — a fieldset is excluded from its own collection, as TheControlsMustRootAtTheFieldsetElement
  already pinned.
• Descending only into elements finds every element descendant, because a form control's ancestors inside
  an element-rooted subtree are always elements. That makes the walk equivalent to
  NodeEnumerable.OfType<HtmlFormControlElement>() without visiting character data.
• The named read reproduces CollectionExtensions.GetElementById's rule exactly — an id match always
  wins, even over a name match seen earlier in tree order.
• The indexed read still throws ArgumentOutOfRangeException outside the range, as GetItemByIndex did.
• input type=image is still excluded; it is a listed element but a submit button rather than a member
  of form.elements.

Tests

Eight new cases in LiveCollectionTests, written and run against the unmodified base first so they
are equivalence tests rather than tests of the new code. Then each was confirmed load-bearing by breaking
the implementation on purpose in five ways — dropping the image exclusion, letting a name match overwrite
an id match, yielding the root, rooting the walk at the form instead of the document element, returning
null instead of throwing, and memoizing Length — and each break fired on exactly its own property.
The memoizing break is caught by HtmlFormLiveCollectionFollowsAppendRemoveAndReparent, which is the one
that matters most here: it is what says the collection is still live.

4075 -> 4083 cases, 0 failed, in both text-source modes (prefetched=false and prefetched=true).
The library builds warning-free on all five TFMs.

Measured

Paired A/B against eb3925b9d, 6 rounds, arms alternating every round, DefaultJob, idle box, each
arm from its own worktree — the baseline carrying this PR's new benchmark file untracked, so both arms
run the same rows and differ by exactly HtmlFormControlsCollection.cs. The median is of the per-round
percentage differences and the interval is a percentile bootstrap over them.

FormElementsNamedLookup is not a row this PR wrote — it came with #1345 and hits this collection
through a different member. It reads the same magnitude independently, which is the closest thing to a
second opinion a single box can give.

FormElementsEnumerate keeps 5,600 B because enumerating through IEnumerable<IHtmlElement> boxes the
struct enumerator once per enumeration; that is the interface's cost, not the walk's, and the other three
rows show what the walk itself now costs. DocumentFormsRead's −0.87 % is not claimed: its interval
only just excludes zero, which on this box is inside the band where a six-round paired bootstrap cannot
be trusted on its own.

Follow-up, deliberately not in this PR

HtmlFormControlElement.Form is the larger remaining cost and it is untouched here. For a control
carrying form="id" it walks to the root and then does root.ChildNodes.GetElementById(formId) — the
recursive scan — once per candidate per read, and there is no id index anywhere in this DOM
(Document.GetElementById is literally that same scan). So form.elements.length is O(K·N) for K
explicitly-associated controls. The obvious pre-filter — a candidate with no form attribute must have
the form as an ancestor — needs care around form="", a non-form id target and a disconnected root, all
of which FormOwnerTests already pins, and it touches files that currently have another PR open on them.
Happy to take it as a separate change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WQwq9NqYqG3kk9M8CKdfdJ