fix: batch large-thread candidates + stop negative-caching uncapped names (closes task/chunk-large-thread-candidates)

Source: task/chunk-large-thread-candidates (plan/steward-linker-quality) — content.js sent all candidates in one call, the server capped at 100, and names past the cap were permanently null-cached and never retried — silently breaking large threads.

- content.js: resolve the per-scan ask set in batches of BATCH (100, <= server MAX_CANDIDATES) via a new pure Extract.chunk helper, so every candidate is actually answered and none is dropped by the resolver's slice.
- content.js: cache only keys actually present in a response (hasOwnProperty); cap-overflow / partial-error / resolver-down names are left out of `resolved` and retried next scan instead of stuck at null.
- extract.js: add pure chunk(arr, size) on the RSLExtract global; extract.test.cjs covers exact-multiple, remainder, under-size, empty, and lossless in-order concatenation.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

extension/extract.js

@@ -221,6 +221,15 @@
     return all;
   }
 
+  // Split an array into consecutive sub-arrays of at most `size` elements (the last is the
+  // remainder). Pure + position-preserving: concatenating the chunks reproduces the input in order.
+  // The resolver client uses it to keep each /resolve request at or under the server's per-call cap.
+  function chunk(arr, size) {
+    const out = [];
+    for (let i = 0; i < arr.length; i += size) out.push(arr.slice(i, i + size));
+    return out;
+  }
+
   // True only for http/https URLs — reject javascript:, data:, garbage, empty.
   // The resolver's url flows into an injected link's href, so the content script
   // re-validates the scheme client-side before assigning it (defense in depth; the
@@ -235,5 +244,5 @@
     }
   }
 
-  return { matchesIn, cueMatchesIn, albumMatchesIn, allMatchesIn, isSafeHttpUrl };
+  return { matchesIn, cueMatchesIn, albumMatchesIn, allMatchesIn, isSafeHttpUrl, chunk };
 });