Use RapidFuzz for server-side fuzzy search

[evnchn]

Motivation

Google SEO favors INP. The Core Web Vitals testing platform is opaque but it appears that CPU is slow, Network is slow.

https://pagespeed.web.dev/analysis/https-nicegui-io/li5rniz6jo?hl=en_GB&form_factor=mobile

Implementation

Can we move the search load to the server-side? Yes we can.

• Remove website/static/fuse.js@7.0.0 and all references
• Add rapidfuzz
• Grab window_state to probe form-factor without round-trip
• await asyncio.sleep(0.2) # debounce which works because If a third task with the same name is created while the first one is still running, the second one is discarded.

End effects:

• Lighthouse mobile 67 -> 70
• Saves 88kB downlink
• Cuts 1 round-trip for data display

Considering that our mean latency across fly.io is 15ms circa (if Claude is to be trusted), and INP for desktop is 71ms, I think that 4x 15ms (up down up down) + 11ms (CPU) network time is the likely current status.

Then INP for desktop after this PR could hit 41ms, and by proportional scaling INP for mobile could hit 107ms which would be a huge win.

Progress

• I chose a meaningful title that completes the sentence: "If applied, this PR will..."
• The implementation is complete.
• If this PR addresses a security issue, it has been coordinated via the security advisory process.
• Pytests have been added (or are not necessary).
• Documentation has been added (or is not necessary).

Final notes

IMO search results actually improved. There are people saying fuse.js isn't the best, and I guess I would agree based on our thing which we are searching through. Ref: https://www.reddit.com/r/nextjs/comments/10yxu92/what_is_your_go_to_clientside_fuzzy_searching/

Less shallow than #5824. Can be adopted together.

Are we ready for the additional CPU load which is needed to sustain the search?

[evnchn]

Btw each call to rapidfuzz takes 1ms, no need run.cpu_bound

[evnchn]

Actually got one more commit at https://github.com/evnchn/nicegui/tree/expt/truncated-search-results which could further mimimize the time (reduce what is being sent, dodge ui.markdown which runs DOMPurify)

But not sure whether server-side fuzzy search is adopted in the end so I'm leaving it here for now.

[evnchn]

Well that's weird. For some reason the new NiceGUI website, though I seem to think it's more visual flare, is actually better in Core Web Vitals that ALL of our pages land in good territory?

Group INP for the worst (and biggest) group https://nicegui.io/documentation/XXX is now 187ms? I guess if it ain't broken don't fix it, so yeah this PR can be archived until our INP is bad again.

I'm still puzzled though 😵