Write up the collection adapters

[FrayxRulez]

A .md at the repo root, alongside the other review docs. No code changes.

Reading SearchCollection after the crash fixed in #3361 turned into a read of the whole area,
and the main finding is worth recording: SearchCollection and IncrementalCollectionView are
two implementations of the same adapter. They differ by one real feature — the search query
driver — and duplicate everything else. IncrementalCollectionView.ReplaceSource is the newer
and cheaper transition (tail adjust, then per-index replace, skipping equal items);
SearchCollection does the same job with an LCS diff on the thread pool, which is what #3361 was
about.

The document covers:

• What the adapters are for — keeping one binding target while the collection behind it is
  replaced, because swapping ItemsSource rebuilds the whole plumbing and Clear() still costs
  a Reset and every container. Close in spirit to CollectionViewSource, except that setting the
  source morphs in place instead of resetting.
• Who uses which, and the two consumers that are on the wrong side: ChatAffiliateViewModel
  uses SearchCollection but never sets Query, and ProfileGiftsTabViewModel has already
  migrated — its SearchCollection line is sitting there commented out.
• Defects in all three files, including several that are still live: _loading has two
  writers (the root of Snapshot the collections before diffing them off-thread #3361, and the snapshot only papers over it), UpdateImpl is async void,
  source changes are dropped during a transition, SearchCollection's mirror has no Replace
  case while IncrementalCollectionView's has no Move, HasMoreItems is a getter with a side
  effect, and MediaCollection.LoadMoreItemsAsync shadows its own count parameter so the
  requested count is silently ignored.
• A proposed direction — converge rather than rename, with SearchCollection keeping its name
  and public API but owning only the query.
• Open decisions, left open rather than guessed.

The one performance claim in it — that the per-index morph beats the diff here — is reasoning
about notification counts, not a benchmark, and the document says so.

🤖 Generated with Claude Code