fix(core): never insert a unified search result above a rendered one

[pringelmann]

• Part of: Unified Search Redesign #60241

Summary

Unified search jumped around while it loaded. Out-of-order results are held back for a short window, but a provider that finished just after that window still landed at its priority slot and pushed everything already on screen down.

Display order is now the order things actually appeared in. Priority still decides which categories wait for which, it just has no say over what has already been painted.

What changes

Priority order is Apps → Files → Contacts. Apps takes 1010 ms, the other two are instant, and the reveal window is 1000 ms.

⬜️ loading · 🟩 loaded · 🟨 blocked

Before

	states	on screen
⏳ 300 ms	⬜️ Apps · 🟨 Files · 🟨 Contacts	nothing yet
⏳ 1000 ms	⬜️ Apps · 🟩 Files · 🟩 Contacts	Files, Contacts
⏳ 1010 ms	🟩 Apps · 🟩 Files · 🟩 Contacts	Apps, Files, Contacts

After. Identical until the window expires, then:

	states	on screen
⏳ 1010 ms	🟩 Apps · 🟩 Files · 🟩 Contacts	Files, Contacts, Apps

Results now clear when a new search starts

The old results used to stay on screen while the next query was in flight, then get swapped and reordered once it landed. That only moved the jumping later. A search now blanks the panel and reveals again from the preferred order.

Results still stay up during the debounce, so this kicks in when the request actually starts, not on every keystroke.

Also fixed

Two ways a category could get stuck waiting on a slow one: it used to be re-blocked for another full window, and after paging it could stay blocked indefinitely.

Other changes

Lowers the reveal timer to 1000 ms from 1500 ms. Slightly less delay when a high priority provider is slow, at the cost of results being out of order a bit more often.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI (mostly test changes, comments)

[kra-mo]

The alternative is letting a recovering category reclaim its slot, which shoves rendered rows back down.

After change of query, it’s fine for a slot to be reclaimed. In general, results from a previous query should hide once the query changes since that might once again lead to jumping around so no special-case insertion should be necessary.

[pringelmann]

The alternative is letting a recovering category reclaim its slot, which shoves rendered rows back down.

After change of query, it’s fine for a slot to be reclaimed. In general, results from a previous query should hide once the query changes since that might once again lead to jumping around so no special-case insertion should be necessary.

Removed the SWR mechanism: results from previous query are now cleared. (this includes changes to the filter)

[pringelmann]

/compile rebase