WIP: validate virtualized list selection state

[aarondglover]

Purpose

Fork-only validation PR for the correctness-first MudSelectExtended virtualization fix. This is the slice intended to become upstream PR 1 after cleanup/rebase.

Problem

Upstream PR CodeBeamOrg#583 fixed off-screen initialized selection by allowing the hidden/shadow list to materialize the full ItemCollection. That restored selection presentation but defeats virtualization for large collections and is consistent with upstream issue CodeBeamOrg#608 (high managed-memory use).

Approach

For virtualized selects:

• keep ItemCollection as the authoritative full value set;
• keep SelectedValues as the authoritative selection;
• materialize only selected values in the hidden list;
• re-apply list-item selection state when virtualized components are reused;
• derive multi-selection display text from the value collection rather than requiring every item component to exist;
• re-key only the tiny virtualized shadow list when externally supplied selection changes, because hosted MudListExtended currently ignores later parameter sets;
• unsubscribe disposed select items from external selection notifications.

Non-virtualized behavior remains unchanged.

Validation

Current head: c05db2b1c96eac96405e0551905e5ee795ec1720

GitHub Actions .NET workflow: passing.

• Build: passed
• Tests: 252 passed, 0 failed
• Existing non-virtualized select tests remain green
• Regression coverage includes virtualized multi/single selection, selection replacement, strict mode, comparer behavior, list item reuse, and scale/component-count checks

Related upstream context

• SelectExtended: Fix Initialized Value Doesn't Show on Input When Multiselection & Virtualize CodeBeamOrg/CodeBeam.MudBlazor.Extensions#583 — initialized multi-select + virtualization fix that introduced full hidden materialization
• High Memory Consumption in MudSelectExtended despite Virtualization working CodeBeamOrg/CodeBeam.MudBlazor.Extensions#608 — high memory consumption despite virtualization
• MudSelectExtended: ItemCollection changes are ignored while the dropdown is open CodeBeamOrg/CodeBeam.MudBlazor.Extensions#645 — confirms hosted MudListExtended.SetParametersAsync drops later parameter updates. Maintainer feedback there is cautious about changing central-commander/select-list communication before a larger remake, so that broader lifecycle work is intentionally not bundled here.

Follow-up slices

1. Benchmark infrastructure (fork PR WIP: add virtualized selection benchmarks #2)
2. Hidden select/list cleanup and measured optimizations
3. Separate library-wide performance audit/follow-ups (fork PR Draft: audit performance across MudExtensions and identify focused follow-ups #3 is the audit document)
4. Async/paged-data virtualization

Keep this PR draft/fork-only until the upstream-ready branch is rebased/cleaned and the final diff is reviewed.

[aarondglover]

Follow-up note for upstream PR preparation:

• CodeBeamOrg issue MudSelectExtended: ItemCollection changes are ignored while the dropdown is open CodeBeamOrg/CodeBeam.MudBlazor.Extensions#645 ("MudSelectExtended: ItemCollection changes are ignored while the dropdown is open") is not fixed or materially changed by either the historical Stage 1 / focused fix or the current focused PR1 implementation.
• Verified at both historical Stage 1 (76b806ec54cdb43c9b5171bbbd10d4759014583f) and current PR1: MudListExtended.SetParametersAsync still suppresses later parameter updates when hosted by MudSelectExtended / autocomplete.
• This is worth mentioning only because MudSelectExtended: ItemCollection changes are ignored while the dropdown is open CodeBeamOrg/CodeBeam.MudBlazor.Extensions#645 sits in an adjacent Select/List lifecycle and parameter-flow area, and we explicitly checked that the focused virtualization work had not inadvertently changed its behaviour.
• No claim is made that PR1 fixes MudSelectExtended: ItemCollection changes are ignored while the dropdown is open CodeBeamOrg/CodeBeam.MudBlazor.Extensions#645, and no permanent MudSelectExtended: ItemCollection changes are ignored while the dropdown is open CodeBeamOrg/CodeBeam.MudBlazor.Extensions#645 regression test is required as part of this focused work.
• If a later broader Select/List architectural change happens to affect the same lifecycle path, MudSelectExtended: ItemCollection changes are ignored while the dropdown is open CodeBeamOrg/CodeBeam.MudBlazor.Extensions#645 is a useful compatibility scenario to re-check at that time.

Benchmark-series note: focused benchmark evidence should remain authoritative as upstream dev -> focused-fix candidate. For any later architectural PR, its authoritative comparison should independently be upstream dev -> architectural PR HEAD. Intermediate graph points can be shown as explanatory evidence. Absolute timing numbers on shared runners are illustrative; structural counts, allocations and scaling shape are stronger evidence.

[aarondglover]

Future architecture note — review before any PR3-style work

This is intentionally not PR1 scope. It records findings from the virtualization investigation so they are not lost before any later Select/List redesign.

Current boundary

• PR1's large performance win is primarily MudSelectExtended-specific: the visible list is virtualized, but the existing hidden/shadow MudListExtended previously materialized the full ItemCollection.
• PR1 deliberately keeps that architecture and bounds the virtualized shadow list to selected values.
• PR1 also contains a generally useful MudListExtended correctness fix: reused virtualized item components re-apply selection state when their parameters/value change.
• The previously discussed broader "PR3" design (data/value state authoritative, rendered components transient, hidden list potentially removed) was design work rather than a completed-and-reverted implementation.

Historical Autocomplete finding

The MudAutocomplete<T> hooks in MudListExtended are old and intentional.

The first MudListExtended implementation, upstream PR CodeBeamOrg#99 / commit 4558e95945041ae9f0492184e020c4980b92fbad (2023-01-28), already had:

[CascadingParameter] protected MudSelect<T> MudSelect { get; set; }
[CascadingParameter] protected MudAutocomplete<T> MudAutocomplete { get; set; }

and explicitly contained:

else if (MudAutocomplete != null)
{
    // Uncomment on Autocomplete Phase.
    // Currently autocomplete doesn't have "SelectedValues".
    //SelectedValues = MudAutocomplete.SelectedValues;
}

Six days later, upstream PR CodeBeamOrg#102 / commit 621ba8d9dec49b760d714a440923d865863b9ac0 introduced MudSelectExtended; the Select integration moved from native MudSelect<T> to MudSelectExtended<T>, while the native MudAutocomplete<T> hook remained.

So the best-supported interpretation is:

MudListExtended was designed from the beginning to serve Select and eventually Autocomplete, but only the Select side appears to have been developed fully.

There is currently no evidence of a completed MudAutocompleteExtended component.

Before any future PR3 push

Revisit this note first and answer:

• Can logical selection/value state be separated cleanly from currently materialized MudListItemExtended component instances?
• Can the Select hidden/shadow list be removed entirely?
• Can the virtualized @key refresh workaround disappear as a consequence?
• Can the central commander / parameter lifecycle be simplified without destabilising existing Select behavior?
• Should the dormant Autocomplete path be preserved, completed, redesigned, or explicitly removed?
• Can the resulting model improve MudListExtended, MudSelectExtended, and any future Autocomplete integration without broadening PR1?

Do not infer an Autocomplete performance defect from the historical hooks alone; probe/benchmark that path separately if later architecture work touches it.

[aarondglover]

Superseded by the cleaned upstream production submission: CodeBeamOrg#648. This fork PR remains as historical investigation/context only.