[firestaerter3]

Follow-up to #964 / #994.

#994 made Repository.AddToQueue store skip_arr_notification and skip_post_import_links. The Repository readers whose callers use the flags still don't select them: GetQueueItem, GetQueueItemByDownloadID, ListQueueItems and ListActiveQueueItems. A stored true reads back as false there. QueueRepository's versions of these lookups already read the flags. Other readers that leave them out (the nzb_path lookup inside AddToQueue, which only uses the ID, and the stremio expiry and failure lists) don't look at the flags.

What that breaks:

• Manual retry: POST /api/queue/{id}/retry goes through Service.ProcessItemInBackground, which loads the item with Repository.GetQueueItem and hands it to the post-processor. An item queued with skip_arr_notification / skip_post_import_links is then processed with both flags false: the arrs are notified and symlinks/STRM files are created anyway.
• SABnzbd queue: handleSABnzbdQueue skips items with SkipArrNotification, but it reads them through ListActiveQueueItems, so they are shown to the arrs.
• SABnzbd history by nzo_ids: the same check, on items read with GetQueueItem / GetQueueItemByDownloadID. The full history already filters on the column in SQL.

How to reproduce: POST /api/import/file with skip_arr_notification: true, then retry the item from the queue page. The arr gets notified.

Changes

Select and scan both columns in the four Repository readers.

Testing

• TestRepositoryAddToQueue_PersistsSkipFlags stores each flag combination through AddToQueue and reads it back through the column and all four readers. It fails on main.
• go test passes for internal/database, internal/api and internal/importer. No frontend changes.

The GetQueueItem / GetQueueItemByDownloadID part has run in our fork since 2026-10-01. The two list readers are new in this PR.