feat(notifications): add per-episode availability notifications

[eunux]

Description

Adds per-episode availability notifications for requested TV series. Right now
Seerr only notifies you when a request becomes available at the media or season
level, which means if you're following a weekly show you don't hear anything
until the entire season finishes downloading. This adds a more granular
notification so users can find out when newly aired episodes become available.

The use case is basically:

• I requested a show thats airing weekly

• I want to know when each new episode lands

• Fixes Ability to send notifications for new episodes of ongoing seasons #480

• Related: [Feature Request] Notification on movie/show status change #891, Granular notifications for partial availability #1361, [Feature Request] Allow episode-level availability notifications for shows currently airing #2027, Notifications for pilot/first episode of a season #2242, Request Available - Expand to single episode releases #2842

This depends partially on the Episode entity work from #1671. The entity and
migration pieces are included here becuase the notification flow needs
episode-level availability records in the data model. The underlying Episode
tracking approach comes from #1671 and this branch is meant to be reviewed as
a dependent follow-up built on that work.

I could have implemented this as a standalone thing without the Episode entity
but #1671 already has the groundwork for episode-level state, so building on
that seemed like the lowest-variance option — keeps the review focussed on the
user-facing behaviour here rather than introducing a competing model for
episode tracking.

Happy to do either of these if maintainers prefer:

• rebase once feat(episodes): add episode availability tracking and sync #1671 lands
• split into a smaller follow-up that assumes the Episode entity has already merged

How the notifications work:

• Weekly/staggered shows: Each newly aired episode triggers its own
  notification as it becomes available. This is the main use case.
• Batch drops (Netflix-style): If every episode in a season shares the same
  air date on TMDB, per-episode notifications are suppressed and the existing
  "Request Available" notification handles it instead.
• Premiere batches + weekly: Shows that drop 2-3 episodes on premiere day
  then go weekly will still send per-episode notifications (the season has
  multiple distinct air dates). You get a small burst on premiere day then
  one per week after that. This is intentional.
• Old episodes: Only episodes that aired after the users request was
  created will trigger notifications. Bulk imports, library re-scans, and
  backfills are silently filtered out.
• Overlap with "Request Available": You can enable both. "Request Available"
  fires once when the entire request completes. "Newly Aired Episode Available"
  fires per-episode as they arrive. The UI descriptions clarify the difference.

Season entity note: The Season entity's updatedAt column was changed from
TypeORM's UpdateDateColumn to DbAwareColumn to match the Episode entity's
timestamp pattern and stay consistent with #1671. Not a behavioural change for
the notification feature itself.

Unique constraint: The final commit adds @Unique(['season', 'episodeNumber'])
to the Episode entity to prevent duplicate rows from concurrent scans. Same
pattern as Blocklist, UserPushSubscription, and Watchlist. This commit
can be dropped if maintainers would rather land it with #1671.

AI Disclosure: Used AI tooling to help inspect the codebase and organise
the work. Changes were reviewed manually, PR description is my own words.

How Has This Been Tested?

• pnpm lint
• pnpm test
• pnpm typecheck
• pnpm build
• pnpm i18n:extract
• pnpm format:check
• Manually verified the notification type shows up in settings
• Checked the episode notification trigger logic against current code paths

Screenshots / Logs (if applicable)

Checklist:

• I have read and followed the contribution guidelines.
• Disclosed any use of AI (see our policy)
• I have updated the documentation accordingly.
• All new and existing tests passed.
• Successful build pnpm build
• Translation keys pnpm i18n:extract
• Database migration (if required)

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 734088fb-ad45-497f-a4a2-f86e696c0d6f

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[fallenbagel]

This should wait till #1671

edit: sorry I just saw that you mentioned it in description too 😅