feat(sources): pin the recently played source to the top of the source list

[silentbil]

What

When you reopen a movie or episode, the source you last actually watched it from is pinned to the top of the source list with a "Recently played" chip, ahead of the normal sort. Focus lands on it, so resuming is one click.

Rules

• One source per title. Each profile keeps one record per title (the last 200 titles). Playing another source or episode replaces it.
• Only sources that really played. A source is saved after 10 s of real playback on it. Pausing, buffering and seeking don't count, and resuming deep into a title counts from zero. A new selection, manual or failover, starts the count over, so a source dropped for being slow or broken never becomes "recent".
• Matched against fresh addon results by URL, then torrent hash + file index, then filename, then source text, always within the same addon. The addon's own entry is saved rather than the copy resolved for playback, since Stalker and HubCloud links get exchanged for one-off URLs.

Where it shows

• The Details source picker, on TV and mobile.
• The player's source menu.
• Series match the exact episode only. Live streams are never saved.

Autoplay

Users with "autoplay single source" never see the list, so autoplay now picks the recent source over its own ranking.

• Autoplay normally fires within ~2 s, as soon as any cached source appears. When a recent source exists but its addon hasn't answered yet, those quick picks hold for up to 6 s.
• The hold ends as soon as the recent source arrives, when the search finishes, or when it arrives but the autoplay quality settings filter it out. After that, autoplay picks as before.
• Titles without a recent source autoplay exactly as before.
• Failover is unchanged: it walks the source list and never re-picks the recent source through autoplay.

Changes

• RecentPlayedSource (model + matcher), RecentPlayedSourceRepository (per-profile DataStore), RecentSourcePlayTracker (the 10 s rule).
• PlayerViewModel feeds the tracker from saveProgress and prefers the record in autoplaySelectBest, holding the quick autoplay picks while it's missing. DetailsViewModel loads the record when sources open. StreamSelector pins the match and draws the chip.
• New string stream_recently_played in English and Hebrew.

Testing

• New unit tests: RecentPlayedSourceTest (8) and RecentSourcePlayTrackerTest (7).
• DetailsStreamCompletionTest, DetailsWatchlistToggleTest and ForcedSubtitleSelectionTest updated for the new constructor parameter; all pass.
• Player, details and recent-source unit suites: 337 tests, all passing.
• Manually checked on an Android TV emulator (API 30), sideload debug build: the source-list pin and autoplay picking the recent source.

🤖 Generated with Claude Code

[ProdigyV21]

Thanks for adding this, remembering the source that actually worked is a useful improvement. Two timing cases need fixing before merging:

1. During a slow source switch, selectedStream changes before streamSelectionNonce/the playback URL changes. The old video can keep feeding progress into the tracker, which can save the newly selected source as recently played even though it never played. Please count playback against the active prepared source and suspend recording while a replacement is resolving.

2. Home Server/IPTV background results can call autoplaySelectBest before the recent-source hold is initialized by the progressive results. That lets another source start before the remembered source gets its chance. Please initialize the gate before starting background lookups and make every autoplay entry point respect it.

Please add regression tests for both cases. The build checks pass and the PR merges cleanly; these are playback-timing gaps, not video-quality concerns.

[silentbil]

Thanks @ProdigyV21 - all issues fixed