fix(tests): moderate re-scan interval to stop multi-user index churn

Lowering VECTOR_SYNC_SCAN_INTERVAL to 5s (previous commit) fixed user
discovery on nc31 but exposed re-scan churn on the slower nc32 runner: each
scan re-queues the user's entire corpus, so a 5s cadence floods the single
processor worker faster than it drains (pending climbed to 20-30+ while
indexed stayed 0, status "syncing").

Discovery latency and re-scan churn are separate knobs. Keep
USER_POLL_INTERVAL short (5s) for prompt discovery — the per-user scanner
runs its initial scan immediately on start, so the corpus is queued once
right away — but restore a moderate SCAN_INTERVAL (30s) so re-scans don't
re-flood the queue. Indexing of the one-time initial scan completes well
inside the test's 90s budget; a note created just after that scan is still
picked up by the 30s re-scan.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docker-compose.yml

@@ -160,15 +160,21 @@ services:
       - TOKEN_STORAGE_DB=/app/data/tokens.db
 
       - ENABLE_SEMANTIC_SEARCH=true
-      # Fast discovery + scan cadence for integration tests: the multi-user
-      # background-sync suite provisions a user, creates a note, then waits
-      # ~90s for it to be indexed. With the production defaults (user-poll 60s
-      # + scan 60s) a freshly-provisioned user often isn't even discovered
-      # within that budget, so the wait times out (note never indexed). Match
-      # the single-user service's short cadence so discovery + scan + index
-      # complete promptly under CI load.
+      # Tuned cadence for the multi-user background-sync integration suite,
+      # which provisions a user, creates a note, then waits ~90s for it to be
+      # indexed. Two independent knobs matter here:
+      #   * USER_POLL_INTERVAL gates how fast the background-sync user manager
+      #     *discovers* a freshly-provisioned user (its scanner runs an initial
+      #     scan immediately on start). The 60s default left too little of the
+      #     90s budget, so drop it to 5s for prompt discovery.
+      #   * SCAN_INTERVAL gates *re-scan* churn. Each scan re-queues the user's
+      #     whole corpus, so a very short interval (e.g. 5s) floods the single
+      #     processor worker faster than it drains on slower CI runners
+      #     (pending climbs, indexed stays 0). Keep it moderate: the immediate
+      #     initial scan already indexes the corpus once; 30s re-scans avoid
+      #     the flood while still catching a note created just after that scan.
       - VECTOR_SYNC_USER_POLL_INTERVAL=5
-      - VECTOR_SYNC_SCAN_INTERVAL=5
+      - VECTOR_SYNC_SCAN_INTERVAL=30
       - VECTOR_SYNC_PROCESSOR_WORKERS=1
 
       # OAuth credentials for background sync (optional - uses DCR if not provided)