fix(zod): keep every declared tuple position

[cmun2]

• I understand that this repository is auto-generated and my pull request may not be merged

Changes being requested

parseTupleDef in the vendored Zod v3 converter builds items with a map that drops any element whose parser returns undefined, while minItems and maxItems are taken from def.items.length. The two disagree whenever an element produces no schema.

zodToJsonSchema(z.tuple([z.void(), z.string()]));

// before
{ "type": "array", "items": [{ "type": "string" }], "minItems": 2, "maxItems": 2 }

// after
{ "type": "array", "items": [{}, { "type": "string" }], "minItems": 2, "maxItems": 2 }

The array-form items keyword is positional, so before this change the schema requires exactly two entries and describes the string element at index 0 — the position the void element occupies. A value the Zod schema accepts is rejected by the schema generated from it, and vice versa. The same shift happens with a rest element, where additionalItems then applies one position too early.

Keeping an unconstrained {} for such an element preserves the alignment and constrains nothing, which is what the element was already saying. Zod v4 describes both positions here, so this also brings the v3 output back in line with v4.

Tuples whose elements all produce schemas are unaffected; a test pins that.

Additional context & links

Split out of #2463. It surfaced there as a regression an earlier revision of that branch introduced, and while fixing it I found the same drop happens without any of that change — a tuple under an object property already hit it, because parseObjectDef has always set propertyPath. The repro above needs no property at all and reproduces on main as it stands. #2463 no longer touches parseDef.ts, so the path that first exposed this is gone from it entirely and the two are independent.

Scoped to one function in src/_vendor/zod-to-json-schema/parsers/tuple.ts.

Testing

• pnpm vitest run tests/helpers/zod-tuple-positions.test.ts — 4 passed.
• With the source change reverted and the tests kept, 3 of the 4 fail. The fourth is a control asserting that ordinary tuples do not change, so it passes either way.
• Full suite: 5353 passed. The 26 failing files are identical to those on main at 222f3d7 and come from optional dependencies that are not installed in this environment (@aws-sdk/*, @smithy/*, ws).
• ./scripts/lint and ./scripts/format: clean for both files.