fix(Library): filter watched sort results

[Cesarsk]

Dear,

I opened this MR as I believe that the Not Watched and Watched options should not be a "sort" option but rather an actual filter. I made a small change that hides the Not Watched items when clicking the filter "Watched". Viceversa, I hid the Watched items in the "Not Watched".

The rationale is that when I want to check what I have not watched yet, I do not want to see items that I have already watched.

similar concept is applied to "Most Watched" items.

Open question

• lastwatched is intentionally unchanged in this PR. Should Last watched also hide not-watched items, or should it continue to show the full library ordered by last watched activity?

Summary

• filter Library results for the Watched and Not watched sort chips so the opposite watch state is not rendered at the end
• filter the Most watched sort to watched items only, since not-watched items have no watch count
• stop requesting more pages once the loaded core-sorted catalog reaches the opposite watch-state group

Thanks for this amazing project, I hope the contribution is appreciated.

L.

[CLAassistant]

All committers have signed the CLA.

[Cesarsk]

I leave here a Security Review, just in case:

Security Review

Findings

No security issues found in the PR diff.

Reviewed Scope

• Commit: 7dacbb06c fix(Library): filter watched sort results
• File changed: src/routes/Library/Library.js
• Relevant lines: 57-75, 82-85, 114, 126

Security Notes

• No new network calls, storage access, auth handling, permissions, or dependency changes.
• No new user-controlled HTML rendering or dangerouslySetInnerHTML.
• The sort value is only matched against fixed string cases: watched, timeswatched, notwatched.
• Unknown or malicious sort values fall back to no frontend filter.
• Rendered items still use the existing LibItem rendering path, so no new rendering sink is introduced.

Residual Risk

• This is a UI-level filter only. Opposite-state items are not rendered, but they may still exist in library.catalog in memory because core returns them.
• This is acceptable for the PR’s UX goal, but it should not be described as a data-confidentiality boundary.
• If core ever returns malformed non-boolean watched values, active watched filters will exclude those items and may stop pagination early.
• Current core serialization returns boolean watched, so this is not a current security concern.

Conclusion

The change is security-safe for the intended frontend behavior.
The only caveat is that it should be described as preventing opposite-state items from being shown in the Library UI for these sort modes, not as preventing access to those items.