Plugin search filters, and the list sorts

Typing into the Plugins search reordered the list and never shortened it, because the npm registry ignores a search term sent beside a keyword qualifier. The catalogue is fetched once and searched locally, with four sorts for available plugins and three for installed ones, and a refused request shows an error with Retry instead of a spinner that never stops.

Typing into Search plugins turned the search icon into a spinner and left the list exactly as it was, which reads as search being broken, because it was.

Two faults. The npm registry does not filter by a term sent alongside a keywords: qualifier: keywords:tabby-plugin tmux and a nonsense term both return the same 149 packages, re-ranked. And a refused request still carries a JSON body, so reading the package list off it threw inside the stream, which ended it and left the spinner turning. The catalogue is now fetched once, paged and cached, and searched locally: every typed word has to match the name, package name, keywords, description or author.

registry requests on page load   6 -> 2
registry requests per pause      4 -> 0
"tmux" on the Available tab   144 -> 4 items

• Relevance with no query keeps the registry's own order, so the default view is unchanged. The other sorts are the ones the data actually varies on: Most downloaded, Recently published and Name for available plugins, and Name, Third-party first and Disabled first for installed ones.
• Dependents and the score breakdown were left out, because they were identical across all 180 packages the registry returned.
• The sort choice is view state and lives in localStorage.

• The stuck spinner in the original report was reproduced with an injected 429 response, not observed from the registry itself.
• Third-party first has only run on a profile with no third-party plugins, where it matches Name.