GetBookByISBNWithOutcome hands every caller the cached book and keys it without provider scope #2869

Impact

Latent, the same class of bug as #2809, on a lookup #2809 does not list. Aggregator.GetBookByISBNWithOutcome (internal/metadata/aggregator.go) stores the enriched *models.Book in the shared 24-hour ttlCache under isbn:<normalized isbn> (cacheISBNBook, a.cache.set(key, book)). A cache hit then returns that same pointer (return cached.(*models.Book), ...).

• Shared object. Any caller that mutates the returned book, or anything reachable from it (Genres, Editions, SeriesRefs, Author), rewrites the cache entry for every later ISBN lookup of that edition. The callers today, internal/api/search.go (ISBN search) and internal/abs/import_upserts.go (lookupUpstreamBook → mergeUpstreamBook), appear to read the result and write only their own row, so I could not construct a user-visible sequence. It is a trap for the next caller that edits the result, as GetBook, GetAuthor and GetEditions hand every caller the cached object, and two callers mutate it #2809 describes for GetBook.
• No provider/credential scope. The key has no provider-configuration scope. After a Hardcover token is added, changed or removed, or the primary provider changes, the ISBN answer built under the old configuration is served for up to 24 hours.

Why this is outside #2615

#2615 (metadata request caching) moves GetBook, GetAuthor, GetEditions and GetEditionsFromProvider onto cloned, provider-scoped cache entries, which fixes #2809. It does not touch the ISBN path, and folding it in would widen that PR beyond the lookups #2809 names.

Suggested fix

Once #2615 lands, give the ISBN lookup the same treatment: clone on store and on hit (cloneBook), and include the bound provider scope in the key (bindCacheProviders), so a configuration change selects a fresh entry. Regression test: look up one ISBN twice, mutate the first result's Genres[0] and OwnerUserID, and assert the second result is unchanged.

The series and canonical/audnex caches (aggregator_series.go, aggregator_enrichment.go) are also unscoped and may share pointers. Their callers have not been traced for mutation, so they are mentioned here only as candidates to check alongside this fix.