v0.6.0

Completeness: the release where you can see what the library is still missing,
and finish it. v0.5.0 told you what automation did; this one answers the
harder question — what it hasn't done, and why. A new Wanted page lists
every episode still missing across the library with the reason for each one,
down to the release the last search found and turned down. Season packs now
import episode by episode, so a back catalogue arrives in one grab instead of a
dozen. And an episode you already hold can be re-grabbed when a better release
appears — opt-in per quality profile, bounded by a cutoff.

Added

• Wanted is a real page: what the library is still missing, and why. Two
  tabs. Missing lists every episode still worth acquiring, grouped by series
  with the newest gap first, and says why each one is still missing —
  automation is off, the series is unmonitored, blocklisted or waiting its
  turn in the search queue, the last grab failed, or it simply has not aired.
  Unaired episodes and unmonitored series sit behind filters, since the
  Calendar owns the forward-looking view. Cutoff Unmet lists episodes you
  hold that score below their quality profile's cutoff, with the release you
  have and what the profile still wants from it ("group TopSubs (+100) ·
  resolution 1080p (+100)"). An episode's Search opens the Releases tab
  focused on that episode; selecting series and hitting Search selected or
  Search all puts them back at the front of the search queue and starts a
  run — the confirmation says queued rather than done, and under notify-only
  that the run will grab nothing. Series headers stay in view while you
  scroll, groups collapse once you are done with them, and both lists page as
  you go rather than loading a whole library at once.

  Missing also says when a search found releases and turned them down. An
  episode blocked by your profile's floor, a blocked group or an exclude used
  to look exactly like one nothing had searched for yet — and those are the
  ones where you have something to change. Each episode carries what the last
  pass decided about it: the release it declined and why, the pinned group it
  is waiting for, the one the download client refused, or that a search
  genuinely found nothing. Under notify-only, a rehearsal's decisions show up
  here too rather than only in your notifier. It is the last pass's answer, so
  the badge is dated — "Releases declined · 2h ago" — and a grab since then
  replaces it. Adds migration 00018 (pass_outcomes).

• An episode you already have can be re-grabbed when a better release turns
  up. Off by default and enabled per quality profile: Upgrade until cutoff
  in the profile editor, with the cutoff picked from the same landmarks your
  score weights compose ("top group, best resolution") rather than typed as a
  bare number. It is a cutoff, not a chase — while what you hold scores below
  it, any strictly better release replaces it; once it reaches the cutoff, the
  episode is left alone forever. A second switch keeps taking the same group's
  v2 or repack of the very file you hold even above the cutoff, since that is a
  fix for a broken release rather than a better one. Upgrades ride the recent
  feed, which costs one request for the whole library; the scheduled search
  never spends a search on a complete series, though a series it searched anyway
  takes an upgrade it happens to find. A manual search now offers releases for
  episodes you already have too, and grabs them without asking about the cutoff
  — profiles inform manual actions and gate only automation. The library file is
  replaced in place, with anything the superseded release left under the same
  episode name (a different container, a sidecar) cleared with it; a failed or
  unresolvable upgrade leaves the episode exactly as it was. Nothing removes the
  superseded torrent from your download client. Adds migration 00017
  (upgrades_enabled, cutoff_score, upgrade_v2_above_cutoff on quality
  profiles, and the release each held episode is holding, backfilled from its
  import).

• Season packs and batches now import episode by episode, and automation
  prefers them. A multi-episode payload used to settle every grab row it
  covered as "downloaded (batch)" — terminal, with the bytes on disk and the
  filing left to you — and automation was deliberately kept away from packs for
  exactly that reason. The importer now walks a completed payload once and maps
  its files onto the episodes the release covered, placing each on its own, so
  the refusal is gone: a back-catalog series that has both singles and a pack
  takes the pack, one grab instead of one per episode. Ranking gained a coverage
  tier to make that happen deliberately rather than by seeder count, below a
  pinned group, and a weekly single-episode release still ranks purely on your
  profile score. A pack whose numbering runs past the entry — a 01-48 pack
  against a 12-episode season — is now refused as a possible absolute/season
  mismatch instead of silently claiming episodes 1-12.

• A payload file for an episode the release never claimed is imported too,
  when that episode exists, is still wanted, and has no download of its own —
  the release titled 03 that ships 03 and 04.

• A stuck import can be fixed by hand from the Activity queue. "Needs import
  fix" rows get a Fix import action listing every file in the payload with
  what its name parsed to, and a per-file episode picker preseeded with the
  importer's own suggestion. Use it when a filename is unreadable and nothing
  could be matched to it. Automation never reopens a settled import on its own.

• An episode's Search button now searches for that episode. It used to hand
  you the series-wide result list and leave you to scan it for the row whose
  Match badge said E7. The Releases tab now opens pre-filtered to the candidates
  that cover the episode you asked about — a single or the batch that contains
  it — with a dismissible chip naming the focus and a count of what is hidden.
  Nothing covering it says so, and offers the full list in one click. The search
  itself is unchanged and still series-wide: Search all wanted and clicking
  the Releases tab directly both stay that way, and a grab is still decided by
  the server.

• The indexer can be pointed at specific Newznab categories. A new
  Categories field on the indexer settings (env
  TRANSPONDARR_TORZNAB_CATEGORIES) takes a comma-separated list of IDs — anime
  is usually 5070 — and sends it as cat= on every search and on the recent
  feed. It matters most for the feed: one page is about 100 entries covering the
  whole endpoint, so on a general-purpose indexer music, books and software eat
  the window an anime release needs to be seen in. Empty is the default and
  keeps today's behaviour exactly — every request unfiltered — so nothing
  changes until you fill it in. A cat you baked into a Prowlarr or Jackett
  feed URL is left alone while the field is empty.

Changed

• The Calendar's "Unmonitored" control is now a filter chip rather than a
  switch. A switch says you are changing a stored preference — which is what
  Monitored on a series is — and using the same control for a view filter made
  both mean less. It is now an "Unmonitored" pill under an Include label,
  lighting up when on and matching the new Wanted page. Same behaviour, same
  keyboard and screen-reader semantics.

• An episode you have with a download in flight now reads as "downloading"
  rather than as simply had — the state an upgrade in progress puts it in.

• One import notification per release, not one per episode. A pack landing
  six episodes now sends a single "Import succeeded" naming the range
  (Episodes 1-3, 5). The generic webhook's payload gains an items array
  carrying the raw numbers — always present, empty for a single-episode import,
  with item_number then 0.

• "Downloaded (batch)" is now "Needs import fix", and says which episode had
  no file and how many files were left unmatched. It means one file could not be
  picked out of a payload, not that a whole batch was refused. When nothing in
  the payload matched an episode, that episode now goes back to wanted and the
  release is remembered, so the next search picks a different one instead of
  parking the item forever.

• A download that holds only an archive now says so, and can be finished by
  hand. Transpondarr does not unpack archives — a scene-style RAR set used to
  settle with a flat "the payload holds no video file", and Fix import then
  opened on an empty list, which was a dead end. The deferral now names the
  archive and how many volumes it spans (a 12-volume set counts as one thing to
  extract, not twelve), and the dialog lists it with what to do: extract it into
  the download folder and retry, which imports the extracted episode. An archive
  is listed beside the payload's files and can never be assigned to an episode.
  An episode an archive holds stays waiting for you on every path — retrying
  before you have extracted anything tells you so and leaves the download where
  it was, and a download holding one loose episode plus an archived one keeps
  the second waiting instead of giving up on it.
  Password-protected and corrupt archives are indistinguishable from healthy
  ones without an unpacker, so all three defer the same way.

Fixed

• A single-file .rar download is no longer filed into the library as the
  episode. A payload that is one plain file was taken as the episode whatever
  its extension, so a torrent containing a lone archive was hardlinked into
  place under an episode's name — a file no player can open, with the episode
  marked as had. Such a payload now defers as the archive it is.

• A downloaded episode whose filename happens to contain an extras word no
  longer parks itself. The payload resolver drops files marked preview,
  promo, nc, ncop and similar so a bundled creditless opening is never
  mistaken for the episode. When those words appear in the episode's own title,
  a folder holding exactly one video filtered to nothing and the grab settled as
  deferred — settled for good, with the file sitting right there. A payload whose
  sole video carries such a word is now imported. A payload where several videos
  all carry one still defers, since there is nothing to distinguish them, and a
  file marked sample is still never imported however alone it is: it is a
  truncated copy of the episode, not a title that happens to read that way.

• A releasing title whose episode count AniList never publishes now adds with
  its episodes. Such a title previously created a series with no wanted
  items and sat at 0 / 0 until a background pass caught up, because the add
  asked only for the episode count — precisely the field that is null. AniList
  exposes the broadcast schedule as a field on the title rather than a separate
  query, so one page of it now rides along in the request the add already makes:
  zero extra API calls, and the item set arrives immediately. Separately, the
  schedule skips an episode when two share a broadcast slot — it reads 1, 3,
  4 — so both the add and the background sync now fill the gaps rather than
  transcribing, which is the only thing that creates an episode nothing else
  ever claimed should exist. A filled-in episode has no air date (a normal state
  here) and resets the series' search cadence, so it is looked for on the next
  pass instead of waiting out an accumulated backoff.

• The feed poll no longer spends AniList requests on title variants. Every
  poll resolved each wanted series' name variants through the metadata provider,
  and currently-airing titles — exactly the ones carrying wanted items — expire
  from the cache every 6 hours, so a library of airing shows could blow AniList's
  budget on a single 15-minute tick. The poll now reads variants from the local
  metadata cache only, serving even a stale snapshot (names don't go bad the way
  episode counts do); a series with no snapshot still matches on its stored
  title, and the bounded sweep covers it with full variants.

• An episode that fell through a gap in the recent feed is now searched
  within the next sweep, not up to a day later. When a busy indexer publishes
  more than one page of releases between two polls, the poll recognises nothing
  on the page it fetches and knows its coverage was broken — but it only warned,
  leaving whatever aired in the meantime to the scheduled search, which with a
  feed configured no longer aims at broadcast times and can be a full day away.
  Such a poll now puts the affected series back at the front of the search
  queue: monitored series still missing an episode that aired inside the gap
  (plus an hour of slack before it, since a rip is published after it airs).
  The reset is deliberately capped at five series per gap event — the same
  number one scheduled pass searches — and skips series already due, so a
  routine gap on a high-volume indexer never queues more searching than the
  schedule can spend.

Upgrade notes

• A long-running series already in your library will gain its full back
  catalogue. This affects monitored series whose AniList entry publishes no
  episode count — in practice the very long ones (One Piece, Detective Conan,
  Pokémon, Crayon Shin-chan). AniList keeps only a recent window of broadcast
  records for these (One Piece's first page starts at episode 1123), so until
  now everything below that window was created by nothing at all and the series
  quietly tracked only its recent tail. On the next metadata refresh or airing
  sync each one materializes its whole run — for One Piece, about 1,170 wanted
  items in place of roughly 25.

  Nothing is grabbed by that write, but the new items are wanted and searchable
  immediately, so expect the series to read as far from complete and to stay in
  the search queue while it drains. It costs no additional AniList requests, and
  no additional indexer load per episode either: a sweep spends one search per
  series, whatever its item count. If you would rather not track a long-runner's
  back catalogue, unmonitor the series before upgrading — an unmonitored series is
  skipped by the metadata refresh and the airing sync, which are the two passes
  that would create the items, and by the search sweep that would go looking for
  them.