feat: "Up Next" row on the overview (next unwatched episode per show)

[fjacques-2025]

What

Adds an "Up Next" row at the top of the overview: for each in-progress (Watching)
show, it shows the next unwatched episode with a quick "✓ Watched" action that
marks it and advances the card to the following episode.

Relates to #1008 (the unwatched "to watch" part) and #903 (quick-mark next episode).

How

• Backend: new GET /watched/upnext returning the next unwatched episode per
  Watching show (server/feature/watched/watched_upnext.go); scans seasons from
  the highest watched one using cached TMDB season details. ContentProvider gains
  SeasonDetails.
• Frontend: UpNext.svelte (a HorizontalList) on the overview; "✓ Watched"
  reuses POST /watched/episode then refreshes.

Design note

Episodes are offered regardless of TMDB air_date: that date is the TV broadcast
schedule and doesn't reflect streaming/replay availability (a fully streamable show
can still have "future" broadcast dates). The broadcast date is shown on each card,
flagging not-yet-aired episodes — broadcast viewers know to wait, streaming viewers
can mark ahead.

Draft — open questions

• Placement: overview row, standalone page, or discover?
• Is a dedicated /watched/upnext endpoint preferred over computing client-side?
• Definition of "next": currently first unwatched episode from the latest watched season.

Not included yet: rating from the card; the "upcoming calendar" half of #1008
(depends on a periodic refresh mechanism, #1048/#1049).

Testing

Ran locally (Go + SvelteKit). Marking advances the card; the row clears when a show
is fully watched.

[IRHM]

Hi, thank you for taking the time on this.

I'll have to think about implementation, I have a feeling this should wait until after we have refreshing of our own data to avoid having to rewrite this feature to use it later.

[fjacques-2025]

Thanks, that makes sense — I'd rather it fit the eventual data-refresh work than be
rewritten later.

For what it's worth, the current implementation is fairly decoupled: it reads the
existing watched episodes and only pulls season details on demand via the existing
content service/cache. So once self-refreshed/stored episode data lands, swapping the
"next episode" lookup to read from it should be a localized change rather than a
rewrite — happy to rework it that way when the time comes.

I'll leave this as a draft for reference. Is the data-refresh mechanism (#1048/#1049)
on the near-term roadmap, and would help on it be welcome? I'd gladly look into it if
it unblocks this.

[fjacques-2025]

Update — I've been running this on my own instance in daily use, and it's working
well. Current state of the feature:

"Up Next" row on the overview — for each in-progress show, its next unwatched
episode, with:

• ✓ Watched — marks it and advances the card to the next episode (also covers Quickly mark Episode as watched #903).
• Drop — one click sets the show to Dropped so it leaves the row, without opening it.
• Season episode count — e.g. S1.E7/30.
• TV air date on each card. Episodes are not filtered on TMDB air_date (that's the
  broadcast schedule, not streaming availability), so it works for streaming/replay while
  still flagging not-yet-aired episodes.

Backend is a single GET /watched/upnext; no schema changes.

Still a draft — I understand you'd rather land this after the data-refresh work so it
doesn't need reworking, happy to align it with that when the time comes. Sharing the
finished state (and that it's been solid in daily use) in case it's useful.

[fjacques-2025]

Small addition (pushed): the Up Next row now follows the same sort as the watched list (GetUpNext binds sort/sortDir and applies the shared watchedRefineSort scope; the frontend passes the current sort and re-fetches on change). Still in daily use on my instance.