v0.7.0

Monitoring, per episode: the release where you choose which episodes
Transpondarr chases, not just which series. Unmonitor a recap, an episode you
already have, or a thousand-episode back catalogue, and automation stops looking
for it — and every progress count now reads against what you actually asked for
rather than against every episode a series will ever have. Activity also gains a
view of the downloads nothing is waiting on.

Added

• Per-episode monitoring. Monitoring was all or nothing per series: once an
  episode existed, the sweep chased it until a file landed — forever. Every
  episode now carries its own flag, so unmonitoring a recap, an episode you
  already have, or 1,038 episodes of a back catalogue takes them out of
  automation for good. Adding a series asks which episodes to monitor — all,
  or future only from the next broadcast onwards — and the answer keeps
  applying to episodes announced months later. The Episodes table gains row
  checkboxes and a bulk monitor/unmonitor toolbar; Wanted gains a per-row toggle
  and an unmonitored reason, with those rows behind the existing Unmonitored
  chip rather than removed, so the click is undoable. A manual search and a
  manual grab still work on an unmonitored episode, and a pack grabbed for its
  monitored episodes still imports every file it carries. Adds migration 00021.
  Closes #188.
• Downloads nothing is waiting on are now visible in Activity. A torrent
  could be left in the download client with nothing pointing at it — after a
  second grab replaced the first, or after deleting a series and choosing to keep
  its downloads — where it kept downloading, took up disk, and could not be seen
  or stopped from Transpondarr. Activity gains an Unmatched downloads section
  listing them with their size, age and state, each removable by hand with the
  option to delete its data too. Nothing is removed automatically, and only
  Transpondarr's own download category is ever listed — torrents outside it are
  yours and are never touched.
  Closes #131.

Changed

• A series' progress is now measured against what it is pursuing, not against
  every episode it will ever have. The denominator counts episodes that are
  monitored and already broadcast, following Sonarr, with the raw total kept
  beside it: a 12-episode show three episodes in reads 3 / 3 (12 total)
  instead of 3 / 12. A series with nothing aired yet says "Nothing aired yet
  (12 total)" and one with nothing monitored says "Nothing monitored",
  rather than 0 / 0; "Search all wanted" is disabled in both cases, because
  there is nothing to search for. The episode table's summary strip splits the
  same three groups — tracked, not yet aired, not monitored.
• The item status have is now in_library, and so is the field it derives
  from. have was the odd one out in a vocabulary of downloading / stuck /
  deferred / wanted, and the web UI has always rendered it as "In library"
  anyway, so this is a rename in the API, not in what you see. The target is
  deliberately not imported: adopting a pre-existing library would put an
  episode in the library without the importer touching it. The
  wanted_items.have column moves with it (migration 00019). No behaviour
  changes. Closes #84.
• A tracked title is now identified by which provider it came from and its id
  there, not by an AniList id column. series.anilist_id becomes the pair
  (provider, provider_id) — the same shape the metadata cache has always used.
  AniList remains the only provider and every existing row migrates to it, so
  nothing about behaviour changes; what changes is that the database no longer
  names its upstream in a column. Rebuilds the series table (migration 00020).
  Closes #74.

Fixed

• An episode you already have can now be searched from the Episodes tab. The
  row's Search button appeared only on wanted and deferred episodes, so an
  episode already in your library could not be searched from the series page at
  all — even though Cutoff Unmet linked to the same view and the server had
  always accepted the request. It is now on every row, in-flight grabs included.
  Closes #195.

Upgrade notes

• Every series card's progress changes on upgrade, including ones with nothing
  unmonitored. Nothing is recalculated or written — the denominator is simply
  counted differently, and the old number stays visible as the total in
  parentheses. The API keeps total unchanged and adds tracked and
  monitored_items beside it, so a client reading the old field still gets the
  old number. in_library does change: it now carries the same
  monitored-and-aired filter, so a held unaired or unmonitored episode cannot
  push a series past its own denominator.

• API clients using X-Api-Key need one search-and-replace; the web UI needs
  nothing. Three fields change on the JSON responses:

  Endpoint	Before	After
  GET /api/v1/series	have: 12 (count)	in_library: 12
  GET /api/v1/series/{id}, POST /api/v1/series	have: true (per item)	in_library: true
  GET /api/v1/series/{id}, GET /api/v1/calendar, GET /api/v1/wanted/cutoff-unmet	status: "have"	status: "in_library"

  The other status values are untouched. The migration renames the column in
  place, so no data moves and a downgrade to 0.6.x needs goose down for
  migration 00019 as usual.

• Breaking API change: adding a series takes a provider pair.
  POST /api/v1/series now expects {"provider": "anilist", "provider_id": 123, "monitored": true}. anilist_id is gone, with no compatibility alias, and
  provider is required rather than defaulted — a default would hide which id
  space the caller meant, which is the ambiguity this change exists to remove. A
  request in the old shape is rejected with 422.

  The series responses change to match: GET /api/v1/series/{id}, the add
  response, GET /api/v1/metadata/search and GET /api/v1/browse/season all
  emit provider and provider_id in place of anilist_id. The web UI ships
  inside the server binary and is updated in lockstep, so this only affects
  scripts and third-party clients calling the API directly.

• The migration rebuilds the series table. It is applied automatically on
  first start and preserves every row, including everything hanging off a series
  — wanted items, grabs, grab history and blocklist entries. As with any
  schema-changing release, back up transpondarr.db before upgrading;
  downgrading to 0.6.x is supported and converts the pair back.