fix: restore array parsing for req.query repeated keys (#7147)

[SAY-5]

Closes #7147.

The bump to qs@~6.14.1 in 4.22.0 (#6972) pulled in qs's new default arrayLimit of 20, which causes the extended query parser to silently collapse repeated-key query strings with more than 20 values into an object (e.g. { "0": "a", "1": "b", ... }) instead of producing an array. This broke consumers that had been passing larger batches of repeated parameters through req.query.ids (the issue reporter hits it with ~20 tenancy IDs).

body-parser already got an opt-out path for the extended URL-encoded middleware, but the parseExtendedQueryString used by req.query for the 'extended' query parser still only passes allowPrototypes: true and otherwise inherits qs defaults — so the regression is only visible on req.query, which is what #7147 reports.

This PR restores the pre-6.14 behavior by passing arrayLimit: Infinity to qs.parse inside parseExtendedQueryString. Repeated-key values of any length round-trip back to an array, matching Express <= 4.21.x.

Test plan

• Added a regression test in test/req.query.js that sends 25 repeated ids values and asserts req.query.ids is an array of 25 strings. Verified the test fails on 4.x without the fix and passes with it.
• Full test/req.query.js suite: 11 passing.

If it would help, I'm happy to open a matching PR against 5.x — the same parseExtendedQueryString lives there with the same defaults.

[krzysdz]

Infinity completely removes protection from sending something like arr[999999]=x and allows creating large arrays by sending just 1 parameter with an index.

PR #7151 (to master) uses a value of 1000 (same as the parameter limit), which is a better idea, but it still relaxes the limit compared to qs 6.14.0.

[SAY-5]

Thanks @krzysdz — good catch. Updated to arrayLimit: 1000 to match PR #7151 and the parameter limit used elsewhere. That still lets apps pass repeated-key arrays up to 1000 elements (which covers the failing real-world case in the issue) while bounding single-parameter expansions like arr[999999]=x.

Also added a second regression test asserting that arr[9999]=x now collapses to an object instead of allocating a sparse array, so the arrayLimit bound stays covered.