feat(library): mark search results already in a Calibre library

[splitsec2]

Per discussion #1372, where you said you were fine with this specific implementation: check whether metadata.db exists, read it if so, and show a check mark saying the book is already there.

Searching for a book you already own gives no hint that you own it, so the easiest way to end up with a second copy is to not remember you have the first. This reads a Calibre metadata.db, read only, and marks matching results with an In library badge in the card, list and compact views and in the details dialog.

Off by default. It sits in Settings, General beside the existing Library URL, with a test button that reports how many books it indexed. No HTTP call, no token, nothing written back.

Matching runs most to least confident: a shared external id, then an ISBN compared in both ISBN-10 and ISBN-13 form, then fuzzy title tokens plus the author surname. The check fails open, so an unreadable database degrades the badge and never blocks a search, and entries are cached for ten minutes with an early refresh when the file changes, so a large library costs one read rather than one per search.

text_match.py is new and shared by the index and the provider, so title, author and ISBN matching stays consistent in one place.

On the provider interface

library_index talks only to a LibraryProvider protocol and knows nothing about Calibre. That is deliberate but it is not speculative generality, it is what let me send you the Calibre half on its own: I run an Audiobookshelf provider on the same interface in my fork, which is where the audiobook side of the badge comes from. I have left that out because it is a new service integration rather than something already in the codebase, which is the line your non-goals draw. Happy to send it separately if you ever want it, and equally happy for the answer to be no.

Adding a library is a module with the LibraryProvider shape plus one line in all_providers().

Verification

• tests/core/test_library_index.py: id, ISBN and fuzzy matching, per-content-type provider selection, fail-open on provider errors, stale-cache reuse, TTL and fingerprint refresh, per-provider cache isolation, and the test-connection path including unsaved form values.
• tests/core/test_text_match.py: ISBN variants and token matching.
• src/frontend/src/tests/libraryBadge.test.ts and the added cases in bookTransformers.test.ts.
• Python suite (3269) and frontend suite (206) green, plus ruff, ruff format, basedpyright, vulture, tsc, oxlint, oxfmt and the production build.

[splitsec2]

Pushed b1e7388, which fixes a false-ownership bug I found after opening this, plus 04b71df adding the provider and search-payload tests the first pass missed.

The matcher compared title tokens in one direction only, so a shorter title was a subset of any longer one sharing its words. Against a real 146 book library that meant "Dune" reported as owned when the shelf only held "Dune Messiah", and the same for "It" against "It Chapter Two" and "Children of Dune". For a badge that is a wrong answer on screen; for anything gating an acquisition on it, the book never gets fetched.

A match is now rejected when the shelf title adds a word the search did not ask for. Getting that to behave on real data took three constraints:

• Only real words count. Volume numbers do not disqualify an entry, because shelf titles carry them far more often than they name a numbered sequel.
• Series and author words are subtracted. Calibre users routinely bake them into the title, so "Alex Cross 25: Cross Kill" is still Cross Kill.
• A trailing parenthetical is dropped from the compared title, since that is where series and edition notes usually sit: "Mary, Mary (Alex Cross Series [Feature Request] Optional use of the AA download API #11)".

Collections are kept rather than rejected, and reported as their own holding, so an omnibus badges as "In a collection" rather than claiming the volume is owned outright. ownership therefore returns "owned" or "collection" per format instead of a boolean.

Two cases it still gets wrong

Stating them rather than leaving them to be found:

• A numbered sequel with no other distinguishing word. "Persepolis" against a shelf holding "Persepolis 2" still reports owned, because the rule deliberately ignores numbers. Ignoring them is the safer default, since treating every number as distinguishing broke real matches on volume-numbered titles.
• A collection whose title uses none of the collection words, such as "Three Jack Reacher Novellas (with bonus Jack Reacher's Rules)", which genuinely contains "High Heat" but reads as a different work.

Both have the same principled fix: Calibre exposes series_index, so a number equal to it is metadata rather than a title word, and that would let numbers be distinguishing everywhere else. I left it out to keep this reviewable, and it is written down on my side as the follow-up.

Verification

• New cases in tests/core/test_library_index.py cover the subset rejection, the repeated series and volume, an edition word, a collection reporting itself, and an outright copy outranking a collection of the same book.
• Frontend tests cover the two holdings and the collection-only case.
• Python suite (3287) and frontend suite (209) green, plus ruff, ruff format, basedpyright, vulture, tsc, oxlint, oxfmt and the build.

[calibrain]

Awesome !
Cant wait to test it !