fix(books): use the author-refresh match instead of independently re-deriving it

[jordanfelle]

Description

RefreshAuthorService's SortChildren already decides, once, which remote item matches each local book (GetMatchingExistingChildren) - that decision is what buckets a book as Added/Updated/UpToDate/Deleted. But when the actual per-book refresh runs, RefreshBookService.GetRemoteData throws that decision away and independently re-derives its own match via BookIdentity.FindWorkFirstMatches(...).FirstOrDefault() over the same raw remote list.

When the remote list has more than one plausible candidate for a book (e.g. the metadata source returning multiple entries that share a provider id), these two passes can disagree. Confirmed live: a book correctly classified as changed (SortChildren's comparison found a real difference) never actually got the field written, refresh after refresh, because GetRemoteData's own separate match resolved to a different candidate.

Adds SortedChildren.MatchedRemoteByLocalId (populated where the match is actually decided, in SortChildren) and threads it through a new, non-interface RefreshBookInfo overload - same reasoning as BookService.UpdateMany's existing hint overload: adding a parameter to IRefreshBookService would break every hand-written test double, so RefreshAuthorService holds a concrete RefreshBookService reference check instead. GetRemoteData consults the hint first and only falls back to independent re-derivation when there isn't one for that book id, so every other RefreshBookInfo caller (imports, discovery, manual single-book refresh) is completely unaffected.

This is one of three related fixes (companion PRs make match-claim order deterministic, and fix a separate comparison-vs-apply mismatch); together they resolve a "books reported as changed on every single refresh, forever" symptom I found while investigating a cover-reconciliation performance issue.

Database Migration

NO

How was this tested?

• New tests in RefreshBookServiceProviderMatchingFixture: with an ambiguous remote list (two candidates that both legitimately match by provider id and media type), a hint pointing at either candidate is honored regardless of list order; a hint entry for a different book id is correctly ignored and falls back to normal matching.
• Full Chaptarr.Core.Test suite (3,022 tests) passes.
• Deployed to a live instance alongside the two companion fixes and confirmed via live logging that a book's match now resolves consistently between the classification pass and the actual update pass.

Screenshots (UI changes only)

N/A - no frontend changes in this PR.

[jordanfelle]

Found in an adversarial review of #218: this PR's per-call hint was an instance field on the singleton RefreshBookService, justified by 'only one disk-access command runs at a time', but RefreshAuthorCommand neither requires disk access nor is type exclusive, so per-author refreshes run concurrently (3 by default, more with #222). One refresh could read another author's hint, and the finally block cleared it under a refresh still using it. Added a commit that holds the hint in an AsyncLocal (property backing, call sites unchanged) and a deterministic two-flow test that fails with a shared field.