feat: add a Music tab fed by TPB, 1337x, and BitTorrented

[ugurckr]

Overlaps #141. That PR proposes the same tab from the same three sources and is still open —
if it lands first, close this one. I'm putting this up because it takes the category boundaries
and the browse-feed problem further (see below), and those parts may be worth lifting either way.

What and why

Music is the one large category the curated list has no answer for: someone after an album has to
search Movies and hope. All three general sources already carry it, so the tab costs three source
entries, not a new integration.

Source	How it's asked
The Pirate Bay	apibay categories 101 (music) + 104 (FLAC)
1337x	its own /category-search/…/Music/ path, /popular-music when browsing
BitTorrented	type=audio

Each gets its own source id rather than a second group on an existing entry, because each asks its
site a different question. Separate ids also keep per-source health and the outage line
("Couldn't reach Music. All 3 sources may be down") honest per tab.

What counts as music

Drawn tightly on purpose:

• 101 + 104. FLAC is where most lossless rips land, so leaving it out would gut the tab.
• Music videos (203) stay video. They're a video file with a video's size and bitrate; someone
  filling a phone with albums doesn't want them.
• Audio books (102) are not music. They belong with books, not between two albums.
• BitTorrented is asked for type=audio, so the tab structurally cannot show a video row —
  the same instinct as the existing video-only restriction, not a name-based filter after the fact.

One existing behaviour changes

The apibay category filter now runs over browse feeds as well as searches (if (q && …) →
if (it.category && …)).

It has to: apibay publishes no top-100 for music alone, so the empty-query feed is the parent
Audio list — music and audio books mixed together. Without the filter, the Music tab's browse view
opens full of audio books.

Movies and TV browse their own leaf feeds (207, 208), which their category sets already admit, so
the filter is a no-op for them. There's a test pinning exactly that so the change can't quietly
regress either tab. A row carrying no category at all is kept rather than dropped — an unfiled row
beats an empty tab.

Grain notes

• MediaType in bittorrented.ts and Category + POPULAR in x1337.ts replace the inline
  "Movies" | "TV" unions and the cat === "Movies" ? … : … ternary, so adding the third value
  was a table entry rather than another branch.
• Games stay FitGirl's alone — none of the new entries claim that group, and there's a test for it.
• No new keys, no new Store fields, no palette or gradient changes. The two new source tags reuse
  their site's existing colour, since the tag answers who found this row, not what kind it is.

Tests

piratebay.test.ts is new (8 cases): the music category boundary including the 203/102
exclusions, the browse-feed filter, the unfiled-row rule, and regression guards that Movies and TV
filtering is unchanged in both search and browse. Plus wiring cases in x1337.test.ts and
bittorrented.test.ts.

npm test goes from 229 to 237 passing.

On my Windows checkout, 5 files (daemon/{runtime,serve,watch}, download/queue{,.safemode})
fail to load with Cannot find module '../../../build/Release/node_datachannel.node' — no C++
toolchain here. Identical on a clean upstream/main, so it's my environment, not this change.

Checklist

• npm run typecheck is clean
• npm test passes
• New logic has a test (vitest; mock node built-ins for platform code)
• If I added a key, I updated both HELP_GROUPS and footerHints in src/ui/keymap.ts
• If I added a Store field, I updated makeStore in scripts/render-previews-impl.tsx
• OS-touching code works on Windows, macOS, and Linux
• One concern, with a Conventional Commits title (feat: / fix: / docs: / chore:)