[OMD-123]

fix(ext/web): reject non-object iterator results in URLSearchParams

The URLSearchParams constructor built its pair list by calling next() on the input iterator and then reading res.done. It only checked for null/undefined, so a primitive iterator result was accepted.

Web IDL's "create sequence from iterable" uses IteratorStepValue, which calls IteratorNext. IteratorNext throws a TypeError when the iterator result is not an Object, and it does so before done is read. A primitive result whose prototype happens to expose done was therefore treated as a completed iteration instead of raising a TypeError.

Check that the iterator result is an object before reading done, so the constructor matches the Web IDL sequence conversion.

// Before: accepted, and `done` was read
let reads = 0;
Object.defineProperty(Number.prototype, "done", {
  configurable: true,
  get() { reads++; return true; },
});
const iterable = {
  [Symbol.iterator]() {
    return { next() { return 1; } };
  },
};
new URLSearchParams(iterable); // accepted

// After the fix: TypeError, and `reads` stays 0

This matches the behavior of Node.js 26.13.0.

Fixes #37117

Testing

• Added urlSearchParamsRejectsNonObjectIteratorResult to tests/unit/url_search_params_test.ts. It asserts that a non-object iterator result raises a TypeError and that done is never read on the primitive result.
• The test was red-verified against the unpatched ext/web/00_url.js: without the fix the constructor accepts the primitive result and reads done once; with the fix it throws a TypeError and reads done zero times.
• Normal construction paths (array of pairs, Map, generator, and iterators that terminate with done: true) produce identical results before and after the change.

AI usage disclosure

This PR was prepared with AI assistance (Claude / Hermes). The reproduction came from the linked issue, the fix follows the Web IDL and ECMA-262 specifications cited above, and the change was verified by running the affected code path directly before and after the patch.

[OMD-123]

Verified against a real Deno 2.9.8 binary (v8 15.0.245.2-rusty).

Running the issue's reproduction on the stock runtime reproduces the bug:

$ deno run --no-config repro.js
{"outcome":"accepted: \"\"","reads":1}

Node.js 26 rejects it:

$ node repro.js
{"outcome":"TypeError","reads":0}

Running the patched constructor logic from ext/web/00_url.js side by side with the stock global in the same Deno process:

PATCHED logic : {"outcome":"TypeError","reads":0}
STOCK global  : {"outcome":"accepted: {}","reads":1}
normal pairs  : [["a","1"],["b","2"]]
normal map    : [["x","y"]]

So the patched path throws before done is read, matching Node.js, and normal construction paths are unaffected.

[CLAassistant]

All committers have signed the CLA.