fix(settings): hide cached title matches the parental lock withholds (#1735)

* fix(settings): hide cached title matches the parental lock withholds

Cross-playlist title matches are cached by their consumers (Actor and
Discover routes, the dashboard trending and recommendation rails and
the four "similar in your portals" rails), so matches found while
unlocked kept advertising locked titles and their playlist names after
a relock. Each consumer now filters on read through a reactive
predicate on the match's provider category, so a relock hides them at
once and an unlock shows them again, without a re-query.

Closes #1723

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(settings): fall back to unlocked copies of a withheld title match

The dashboard trending and recommendation rails and the "similar in your
portals" rails picked one match per title at load, so hiding a withheld
match lost a copy of the same title in an unlocked portal. They now keep
every row the lookup returned and pick the match on read from the rows
the parental lock does not withhold. Adds the release note.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(settings): derive the recommendations seed heading from the visible cards

The rail kept only the seeds that contributed a card to the original
selection, so a seed whose recommendations filled in after a relock (or
an offline prune) was missing from the "Because you watched" heading.
Every seed of the load is kept in order and the heading lists those that
contribute a card now.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: 4gray <fourgray@proton.me>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

docs/architecture/parental-lock.md

@@ -150,8 +150,19 @@ nothing while `withholdsEverything` is true, in either case. The VOD
 multi-source host keys its discovery session to the lock version: a lock
 change drops the discovered sources, retires discoveries and switches in
 flight, and rediscovers through the worker's new lock state. Title-match
-results cached by the Actor/Discover routes and dashboard services are not
-yet retired on relock (tracked in #1723).
+results are cached by their consumers (Xtream/Stalker Actor and Discover
+routes, the dashboard trending and recommendation rails, the four
+"similar in your portals" rails), so each filters them on READ through
+`CatalogTitleMatchService.visibleMatches` / `isWithheld` or
+`CrossPortalSimilarService.visible`. Every match carries its provider
+category id, and the predicate reads the lock state, so a relock hides
+matches cached while unlocked (and those of a lookup issued before it) at
+once, with no re-query; an unlock shows them again. Consumers keep ALL the
+rows a lookup returned and pick a title's match from the visible ones on
+read (the Actor/Discover indexes, the trending rail, the recommendation
+rail through `buildRecommendationItems`, and each "similar" item's
+`candidates`), so a title that also exists in an unlocked portal stays
+available through that copy instead of disappearing with the locked one.
 The window before the initial read settles is treated the same way
 (`ParentalLockLockStore.readable` is false until then): settings can report
 the feature as on before the locks are known — and the workspace route's