Import list "specific book" add ends up monitoring (and grabbing) the author's entire catalog within hours

Start by tracing RefreshAuthorService.ShouldMonitorNewBook and AddChildren, then inspect MonitorNewBookService.ShouldMonitorNewBook and ImportListSyncService.BuildMonitoringConfigForGoodreadsImportList. Compare the monitor-new-items value and specific-book selection when the initial import persists the author with what the refresh reads; use DEBUG logs to identify the branch that marks the extra books monitored. Done means a regression test covers a GoodreadsBookshelf specificBook import followed by an author refresh and confirms other books remain unmonitored.

Chaptarr version 0.9.936+ (confirmed on latest develop, commit 7a06004).

Bug: A GoodreadsBookshelf import list configured with shouldMonitor:"specificBook" correctly scopes the initial add to just the one book on the shelf — but roughly 60–90 minutes later, once the author's periodic metadata refresh (RefreshAuthorService) runs, other books by that same newly-added author silently flip to monitored and get grabbed too, even though the author's own AudiobookMonitorNewItems/EbookMonitorNewItems is correctly stored as None.

Two real-world reproductions, both via GoodreadsBookshelf lists with shouldMonitor:"specificBook", monitorNewItems:"none":

1. 2026-09-17 — a shelf added one book, "The Good Girl Effect" by Sara Cate. Within the day, 47 file-editions across 30 distinct Sara Cate titles were grabbed (her entire back-catalog). Same pattern, smaller scale, hit "I Will Break You" by Gigi Styx (1 listed → 7 titles/13 editions grabbed) from the same shelf sync.
2. 2026-09-19 — a shelf added three books: "The Halls of the Dead" (S. M. Hallow), "The Other Moctezuma Girls" (Sofia Robleda), "Muñeca" (Cynthia Gómez). Chaptarr's own Info-level log shows the initial add was correctly scoped:

2026-09-19 02:03:53.6|Info|ImportListSyncService|Queued author from import list for background import (author pass): Cynthia Gómez
2026-09-19 02:03:53.6|Info|ImportListSyncService|Queued author from import list for background import (author pass): S. M. Hallow
2026-09-19 02:03:53.6|Info|ImportListSyncService|Queued author from import list for background import (author pass): Sofia Robleda
2026-09-19 02:04:14.8|Info|ReleaseSearchService|Searching indexers for [Cynthia Gómez - Muñeca]. 1 active indexers
2026-09-19 02:04:19.4|Info|ReleaseSearchService|Searching indexers for [Sofia Robleda - The Other Moctezuma Girls]. 1 active indexers
2026-09-19 02:05:29.5|Info|ReleaseSearchService|Searching indexers for [S. M. Hallow - The Halls of the Dead]. 1 active indexers

Only the three requested titles searched — correct. Then, ~76 minutes later, the routine per-author refresh ran:

2026-09-19 03:20:06.3|Info|RefreshAuthorService|Author Cynthia Gómez was updated from API (...)
2026-09-19 03:20:12.0|Info|RefreshAuthorService|Author Sofia Robleda was updated from API (...)
2026-09-19 03:20:12.7|Info|RefreshAuthorService|Author S. M. Hallow was updated from API (...)

Ten minutes after that, searches began for four titles that were not on anyone's shelf:

2026-09-19 03:30:23.6|Info|ReleaseSearchService|Searching indexers for [Cynthia Gómez - The Nightmare Box and Other Stories]. 1 active indexers
2026-09-19 03:30:25.9|Info|ReleaseSearchService|Searching indexers for [Sofia Robleda - Daughter of Fire]. 1 active indexers
2026-09-19 03:30:51.6|Info|ReleaseSearchService|Searching indexers for [Cynthia Gómez - Split Scream Volume Two]. 1 active indexers
2026-09-19 03:30:55.0|Info|ReleaseSearchService|Searching indexers for [S. M. Hallow - How To Survive This Fairytale]. 1 active indexers

GET /api/v1/book?authorId=... afterward showed every book row for these three authors — including ones never grabbed yet — at monitored:true, despite GET /api/v1/author/{id} showing audiobookMonitorNewItems:"none" / ebookMonitorNewItems:"none" on all three (the value the import list explicitly set at add time, per ImportListSyncService.BuildMonitoringConfigForGoodreadsImportList, AudiobookMonitorNewItems = importList.MonitorNewItems).

Suspected code path (not yet confirmed with DEBUG-level logs — this is the strongest lead from reading the source, not a certainty):

RefreshAuthorService.cs, ShouldMonitorNewBook(Book addedBook, Author entity, bool isAudiobook) (~line 1865):

private bool ShouldMonitorNewBook(Book addedBook, Author entity, bool isAudiobook)
{
    if (addedBook == null || entity == null || addedBook.MediaType != (isAudiobook ? BookMediaType.Audiobook : BookMediaType.Ebook))
    {
        return false;
    }

    // AddOptions remains present until the initial disk scan completes...
    if (entity.AddOptions != null)
    {
        return false;
    }

    var monitorNewItems = entity.GetMonitorNewItemsForMediaType(isAudiobook);
    return monitorNewItems.HasValue &&
           _monitorNewBookService.ShouldMonitorNewBook(addedBook, entity, monitorNewItems.Value);
}

used by AddChildren (~line 1840) when the refresh discovers book rows not yet present locally. MonitorNewBookService.ShouldMonitorNewBook itself correctly returns false for NewItemMonitorTypes.None — so on paper this should have kept the four extra books unmonitored. Since the observed behavior contradicts that, either:

• entity.GetMonitorNewItemsForMediaType(isAudiobook) isn't returning the value actually stored on the author row at the moment the refresh runs (timing/caching issue?), or
• these particular books didn't go through this AddChildren gate at all (e.g. a different insert path for "book exists in bibliography snapshot from initial add but wasn't grabbed yet" vs. "genuinely new to the local catalog"), or
• something between the original MonitoringConfig (SpecificBook + explicit AudiobookBooksToMonitor/EbookBooksToMonitor list, built correctly in ImportListSyncService.BuildMonitoringConfigForGoodreadsImportList) and the author row that actually gets persisted loses the "only these specific books" intent, and the refresh's "new item" classification for these four titles is being computed against a mode other than the author's own MonitorNewItems.

I don't have a DEBUG-level capture from either incident (both discovered after the fact) — flipping logLevel to debug in advance and reproducing on the next scheduled refresh would nail the exact branch. Flagging what I found in case it saves someone the initial trace.

Impact: For any household/shared-library use of GoodreadsBookshelf with shouldMonitor:"specificBook" (the documented way to track one person's list without inheriting their author's whole back-catalog), one person adding a single book to their shelf silently triggers dozens of unwanted grabs about an hour later — real bandwidth/storage cost, and easy to miss since the initial add looked correctly scoped.

Workaround used: manually unmonitor the affected authors and the individually-created stray book rows (PUT /api/v1/book/monitor {bookIds, monitored:false} — reliable; PUT /api/v1/author/{id} monitored:false is not, see #17), then delete the wrongly-grabbed torrents/files once past the tracker's Hit & Run grace period.