lists: cap login list subscriptions to the §17 read set (≤8)

The cold-login REQ storm came from list subsystems subscribing/fetching across
the user's full NIP-65 relay set (often ~20) instead of the documented §17 read
cap. The fetchListIncrementally paths already route through capReadRelays, but
the live subscriptions and direct pool.list calls bypassed it:

- userBlocks.ensureBlockListSubscription: cap the live block-list subscription
- subscriptions.ensureSubscriptionListSubscription: cap the live follows-list
  subscription
- hashtagPreferencesService: cap the relay set used by pool.list + fetch

capReadRelays keeps the user's own relays first and guarantees the reserved
defaults, bounded to MAX_SUBSCRIBE_RELAYS (8). Trade-off accepted: a list event
living only on a user's 9th+ relay may sync on a later pass rather than at login.

Regression: tests/user-blocks-relay-cap.test.mjs.

Co-Authored-By: Claude Opus 4.8 <[email protected]>

js/services/hashtagPreferencesService.js

@@ -22,7 +22,7 @@ import {
 import { sanitizeRelayList } from "../nostr/nip46Client.js";
 import { normalizeHashtag } from "../utils/hashtagNormalization.js";
 import { profileCache } from "../state/profileCache.js";
-import { DEFAULT_RELAY_URLS } from "../nostr/toolkit.js";
+import { DEFAULT_RELAY_URLS, capReadRelays } from "../nostr/toolkit.js";
 import { relayManager } from "../relayManager.js";
 import {
   DEFAULT_NIP07_ENCRYPTION_METHODS,
@@ -686,7 +686,8 @@ class HashtagPreferencesService {
     }
 
     const readRelays = relayManager.getReadRelayUrls();
-    const relays = readRelays.length > 0 ? readRelays : Array.from(DEFAULT_RELAY_URLS);
+    // capReadRelays bounds to the §17 read cap (≤8) so this doesn't fan out across the full NIP-65 set at login.
+    const relays = capReadRelays(readRelays.length > 0 ? readRelays : Array.from(DEFAULT_RELAY_URLS));
     if (!relays.length) {
       if (wasLoadedForUser) {
         userLogger.warn(