Fix qBittorrent service not reloading config after settings change

Root cause: Singleton caching issue
The qBittorrent service uses a singleton pattern with a configLoaded flag.
Once initialized, it NEVER re-reads the database config, even when the
user changes settings via the admin settings page.

Flow showing the bug:
1. Wizard saves download_dir to database ✓
2. First torrent: service reads config, creates singleton, sets configLoaded=true ✓
3. User changes download_dir in settings page ✓ (database updated)
4. Next torrent: getQBittorrentService() returns CACHED singleton ✗
5. Cached singleton has OLD download_dir value in this.defaultSavePath ✗
6. Category check shows "already has correct save path: /old/path" ✗
7. Download goes to wrong location ✗

The singleton check (line 745):
  if (!qbittorrentService || !configLoaded) {
    // Only runs if service doesn't exist or config failed
  }
Once both exist, this block is SKIPPED forever!

Fix:
1. Added invalidateQBittorrentService() function
   - Resets qbittorrentService = null
   - Resets configLoaded = false
   - Forces reload from database on next use

2. Call invalidation from settings APIs:
   - After updating paths (download_dir, media_dir)
   - After updating download client (URL, credentials)

3. Next torrent addition:
   - getQBittorrentService() sees null singleton
   - Re-reads config from database
   - Creates new service with current download_dir
   - Category updated with correct path

Benefits:
- Settings changes take effect immediately
- No app restart needed
- Category save path always matches current config
- Download client credentials always current

Updated documentation to explain singleton invalidation pattern.

documentation/phase3/qbittorrent.md

@@ -50,6 +50,12 @@ Free, open-source BitTorrent client with comprehensive Web API.
 
 Validation: All fields checked before service initialization.
 
+**Singleton Invalidation:**
+Service uses singleton pattern for performance. When settings change (via admin settings page), singleton is invalidated to force reload:
+- `invalidateQBittorrentService()` called after updating paths or download client settings
+- Forces service to re-read database config on next torrent addition
+- Ensures category save path and credentials are always current
+
 ## Category Management
 
 **Category:** `readmeabook` (auto-created for all torrents)
@@ -97,7 +103,10 @@ type TorrentState = 'downloading' | 'uploading' | 'stalledDL' |
 **6. Race condition on torrent availability** - Fixed with 3s initial delay + exponential backoff retry (500ms, 1s, 2s)
 **7. Error logging during duplicate check** - Removed console.error in getTorrent() during expected "not found" cases (duplicate checking)
 **8. Prowlarr magnet link redirects** - Some indexers return HTTP URLs that redirect to magnet: links. Fixed by intercepting 3xx redirects before axios follows them, extracting the Location header, and routing to magnet flow if target is a magnet: link
-**9. Category save path not updating** - When user changes `download_dir` setting, category keeps old path. Fixed by calling both `createCategory` and `editCategory` on every torrent addition to ensure category path matches current config
+**9. Category save path not updating** - When user changes `download_dir` setting, category keeps old path. Fixed by:
+   - Checking existing categories before create/edit (avoid unnecessary 409 errors)
+   - Invalidating service singleton when settings change (forces config reload)
+   - Settings API calls `invalidateQBittorrentService()` after updating paths or credentials
 
 ## Tech Stack