Add client-side search/filter and sort-by-popularity to the plugins page

Problem

krew.sigs.k8s.io/plugins renders the full plugin list (currently 250+ plugins) with no way to search, filter, or sort it. Finding a specific plugin means Ctrl+F or scrolling the whole table, and there's no way to surface popular/well-maintained plugins first.

Related requests for discoverability have been open for years but stalled on a harder, separate problem — defining a plugin categorization/keyword taxonomy in the manifest schema (#406, #26). That schema debate (categories vs. keywords, controlled vocabulary, burden on private/self-hosted index maintainers) doesn't need to block basic search/sort on the website.

Proposal — phased, decoupled from the taxonomy debate

Phase 1 (this issue's scope): client-side search/filter

• Add a search input above the plugin table.
• Filter client-side against fields already present in the existing data (name, shortDescription).
• No plugin manifest schema change, no burden on krew-index or any private/self-hosted index — only touches site/ rendering of data already fetched.

Phase 1b (this issue's scope): sort by GitHub stars / popularity

• Add a sort control: alphabetical (current default) vs. popularity (GitHub stars).
• Star counts fetched from each plugin's homepage (when it's a GitHub repo) at site build time (e.g. via GitHub's REST API in the Hugo build/data pipeline), cached into the generated plugin JSON/data file — not fetched client-side per visitor, to avoid GitHub API rate-limiting and keep the page static-fast. This revives the shields.io/stars idea floated in #519's discussion but bakes it into a sortable column instead of just a badge.
• Plugins without a resolvable GitHub homepage (or private index entries) simply sort last / fall back to alphabetical — no hard failure.

Phase 2 (follow-up, explicitly out of scope here): optional free-text keywords

• If there's still appetite later, add an optional spec.keywords: [] manifest field to improve match ranking. Free text, no controlled vocabulary — avoids the "who owns the category list" problem from #406. Purely additive: absence of keywords never excludes a plugin from results.

Filing Phase 1/1b as one issue since they're independently mergeable and don't require resolving the categorization debate.

Related

• #406 — Proposal: Categorize kubectl plugins (stalled on categories-vs-keywords design disagreement)
• #26 — Use plugin description in search command (same discoverability problem, CLI-side)
• #519 — site: Show dynamic plugin list on a website page (built the current plugin table this issue proposes adding search/sort on top of; also floated GitHub-stars display)