Derive series labels from series links instead of stale snapshots

[tillkruss]

Description

Fixes #34.

Series labels come from Book.SeriesName/SeriesPosition, stamped once at add time and never re-derived — so books show a series in the wrong language, a number borrowed from another series (The Way of Kings → The Cosmere Universe #1, where the 1 is Stormlight's), or a series on a book that isn't in one. Building Ruddarr for iOS made it worse: a book turns up under several alias series from different sources, and the label can't be matched back to one — gr:135117 is The Cosmere Universe in the scalar and The Cosmere in the links.

SeriesBookLink is reconciled on every refresh, so it becomes authoritative. BookSeriesLabel picks one link and formats Title #Position from it, so both halves always come from the same series; the API, FileNameBuilder and a refresh-time repair all use it. Also exposes seriesType/parentSeriesId so clients get the hierarchy instead of inferring it.

Database Migration

NO. No schema change, but a refresh rewrites existing Books.SeriesName/SeriesPosition from the links — that's what repairs already-added books. Books without links are untouched.

How was this tested?

New fixtures in Chaptarr.Core.Test/Books: BookSeriesLabelFixture, BookResourceSeriesTitleFixture, BookServiceResyncDenormalizedSeriesFieldsFixture.

[nik110403]

Thanks for working on this. A saved rename preview from my 0.9.965 audiobook library shows The Way of Kings under The Cosmere/6 instead of the intended The Stormlight Archive/1, and Words of Radiance under The Cosmere/8 instead of The Stormlight Archive/2. That supports the problem reported in #34. I have not run this PR against the live library, so this is source-review feedback rather than a verified before/after result.

Two naming edge cases look worth covering in tests:

1. ResyncDenormalizedSeriesFields copies link.Position?.Trim() into the stored position. Could a synthetic link with a multipart position such as 1, 1, Part 1, 1, Part 2 establish the intended output for {Book SeriesPosition}? It would be useful to pin whether that list should remain literal or reduce to a single volume position.
2. FileNameBuilder still prefers an existing nonempty Book.SeriesName, using the selected link as a fallback. Please clarify or test when refresh/resync repairs that stored pair, so a user can tell when the new resolver takes effect in rename previews.

GitHub currently reports this PR as conflicting with develop. Keeping one shared resolver rather than adding a competing series-selection implementation seems the right direction.

[tillkruss]

@nik110403 Thanks for the read. Rebased onto develop and addressed your comments.