client-side search improvements

[PhilipTrauner]

• when the (partial) name of a category is part of the search term, strip it from term and specify it as category query parameter instead

  this has to be done client-side, as the server is (and will remain) unaware of translations

  this could involve splitting the search term on whitespace, and running a string distance function on each word that compares the word with all translated category names
  there are presently ~70 categories, with a 3 word term that would result in ~210 comparisons when performed naively
  to bring down the category candidate amount, it would likely be beneficial to group them based on their first letter, and only attempt comparisons for term words with that same first letter

  jaro-winkler distance (npm package) is a good candidate, as it weights similarity more heavily towards the start, than at the end, as opposed to e.g. levenshtein, which doesn't do positional weighting

  this is just one approach, if the same result can be achieved with a different approach, that is fine as well

• use tokenized search where appropriate

  currently most filtering of "static" data follows the same pattern:

  const term = "Ba";
  const things = [["foo", 10], ["bar", 21], ["baz", 8]] as const;
  things
    .filter(([thing]) =>
    	thing.toLocaleLowerCase().includes(term.toLocaleLowerCase()),
    )
    .toSorted(([, aCount], [, bCount]) => bCount - aCount);

  this approach falls short for multi-word terms with mismatching order or when an unrelated word is included
  to solve this, a ranking approach should be adopted instead

  category / manufacturer section of global search, category filter modal / sheet, and manufacturer filter modal / sheet are likely appropriate places to adopt tokenized search

  potential libraries: fuse.js, MiniSearch, <insert-better-library-here>

  regardless which library ends up being used, there should be a way to influence ranking based on e.g. submission count, and a way to highlight matching text segments