feat: add a Books tab for e-books, comics, and audio books

[ugurckr]

Revisits #118, which proposed this as two tabs and was closed. I've argued the one-tab case
below; if the answer is still no, closing this costs nothing. Also touches the same apibay
browse-filter lines as #150 (Music) — whichever lands first, I'll rebase the other.

What and why

Books are the other large category the curated list has no answer for, and both general sources
already carry them:

Source	How it's asked
The Pirate Bay	apibay 601 (e-books) + 602 (comics) + 102 (audio books)
BitTorrented	type=ebook

No new integration, no new site to trust — two source entries over indexes torlink already talks to.

One tab, not two

#118 proposed E-Books and Audiobooks as separate categories. I think one tab is the better
shape, for three reasons:

1. The format is already in the torrent's name. .epub, .pdf, .cbz, m4b, "narrated by" —
   the row tells you what it is without a tab having to.
2. They share every source. Two tabs means asking the same two sites twice for what one
   request answers, and torlink is a client that cares about how many requests a tab costs.
3. The user's intent is usually "this book". Someone after a novel often doesn't care whether
   it arrives as EPUB or as narration — and if they do, the name says so.

The tab is also where FitGirl's exclusion logic points: books are inert text and audio, the same
class as video and subtitles, so they need no special trust treatment.

Out of scope, deliberately: libgen-style single-book fetching. Those services publish
thousand-book archive dumps, not one book per torrent, so they'd fit the tab badly.

Browse needs two feeds

The two halves live under different apibay parents — 600 (Other) for e-books and comics, 102 for
audio books — so the empty-query view merges two top-100s. fetchBrowse settles for a partial
list: one feed answering beats reporting the whole source down, while both failing still
throws, so a real outage still reaches the tab's error line. Both paths are tested.

The category filter now runs over browse feeds too (if (q && …) → if (it.category && …)),
which it has to: 600 is a parent feed carrying far more than 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 regression test pinning exactly that, in both search and browse. A row with no
category at all is kept rather than dropped: an unfiled row beats an empty tab.

Grain notes

• MediaType in bittorrented.ts replaces the inline "video" literal, so the second value was a
  type entry rather than a new branch. type=ebook means the tab structurally cannot show a
  video row.
• Games stay FitGirl's alone — neither new entry claims that group, with a test for it.
• No new keys, no new Store fields, no palette or gradient changes. The new tags reuse their
  site's existing colour.

Tests

piratebay.test.ts is new (7 cases): the three-category boundary, the two-feed merge, one feed
down (partial list), both down (throws), the unfiled-row rule, and Movies unchanged in search and
browse. Plus a wiring case in 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:)