fix(search): cache paging data before combining, not after

[Pierroons]

Typing into the search bar kills the process on the first keystroke:

java.lang.IllegalStateException: Attempt to collect twice from pageEventFlow,
which is an illegal operation. Did you forget to call
Flow<PagingData<*>>.cachedIn(coroutineScope)?
    at androidx.paging.PageFetcherSnapshot$pageEventFlow$1.invokeSuspend(PageFetcherSnapshot.kt:82)
    ...
    at androidx.paging.compose.LazyPagingItems$collectPagingData$2.invokeSuspend(LazyPagingItems.kt:168)

Cause

A PagingData taken straight from a Pager may only be collected once.

AppViewModel.channels combines three sources, and combine re-emits the
latest value of every source whenever any single one of them changes.
extensionSearchResults always emits twice per query — an empty placeholder
first, then the results — so the same PagingData reaches the collector a
second time and Paging throws.

cachedIn was already there, but placed after the combine, where it
receives the duplicate rather than preventing it. Moving it onto
localSearchResults makes the stream multicast; filter and
insertHeaderItem still run on every collection, which is what they are meant
to do.

Why it looked like something else

Search appeared to return nothing, so the SQL was the natural suspect — it is
not at fault. The process simply died before any result could be rendered.

Tests

Two, and the second is the point: it builds the same shape without the cache
and asserts that Paging rejects the second collection. A regression here would
otherwise pass a green suite quietly, since the symptom is an empty list rather
than a failure.

a cached stream tolerates the re-emission combine causes
an uncached stream is rejected on that second collection

Verified on device (Android 9, arm64): before, the process died on the first
keystroke; after, a search returns its results and survives several queries in
a row.

[oxyroid]

thanks for your contribution