types/rtti/data: make tuples open - #1680

`toData` mapped a `Tuple` to `{ prefix }`, which the data form reads as an
exact length, while `parse` and `validate` treat tuples as open. The same
schema therefore gave two answers depending on which reader consumed it.

`toData` now maps a `Tuple` to `{ prefix, rest: unknown }`, and
`arraySetValidate` reads a position past the array's end as `undefined` —
the rule the object side already applies to keys — so a position is required
exactly when its set excludes `undefined` and no minimum length is tested
for. `../validate/proof.f.mjs` runs its acceptance table through the data
form as well, so the three readers cannot drift apart again.

Changelog:
- **BREAKING CHANGES:** `types/rtti/data`: `toData` maps a tuple schema to the
  open `{ prefix, rest: unknown }`, matching `parse`/`validate` acceptance;
  `{ prefix }` alone is now the exact-length set. Tuples render with a rest
  element (`readonly[42,...readonly(unknown)[]]`) and as JSON Schema with
  `items` rather than `items: false`.

…sitions

Two consequences of open tuples, both found by the review bot on #1680.

`[unknown]` and `[]` are both every array, but only the second normalized to
`{ array: true }`, so one set had two spellings and `equal` said false.
`arraySet` now drops a trailing position stating exactly its `rest`, when the
`rest` admits `undefined` — without that proviso the two differ on a present
`undefined`, so `{ prefix: [number], rest: number }` stays "one or more".

`toTs` printed a trailing position the array may end before as required, so
the emitted TypeScript rejected `[]` for a schema that admits it. It now
prints those positions optional, as the object side already prints the key
they are the counterpart of.

The guard was right, its stated reason inverted. The two spellings do not
differ on a present `undefined` — `{ prefix: [number], rest: number }` rejects
`[undefined]`, position 0 reading a value `number` excludes, and so does
`{ prefix: [], rest: number }`. They differ on exactly one value, `[]`: the
arrays that stop before the position are the ones it reads `undefined` at, and
the `rest` alone imposes nothing there. That absent case is what makes the
untrimmed pattern "one or more numbers", as `data/proof.f.mjs` already said.

Reported by @o2alexanderfedin on #1680.

The extra-entry filter tested `Number(k) >= pn`, which is false for a
non-index key — `Number('foo')` is `NaN` — so an enumerable property on an
array was dropped from validation entirely. `parse` and `../validate` walk the
value's entries rather than its length and hold `foo` to the element type, so
the data form accepted what they reject, which is the parity this branch
exists to restore.

The filter now keeps every entry the prefix has not declared, non-index keys
included, and the no-`rest` case rejects on that same set rather than on
`value.length` — the exact-length pattern's "nothing past the prefix" now
covers a non-index key too, where the previous reading of it panicked on an
absent `rest`.

Reported by the Codex review bot on #1680.

`Number(k) < pn` treated any key coercing into the prefix range as a declared
position, so `'-1'` was skipped from validation entirely — accepted by the
data form, rejected by `parse` and `../validate`, the parity break again —
and `'01'`, `'1.5'` and `' 1'` were skipped by any pattern with a long enough
prefix.

`arrayIndex` rounds the number back through `String` and compares it against
the key, which rejects every non-canonical spelling at once rather than one
at a time: only the canonical spelling of a non-negative integer names a
position, and everything else is a property of the array object, held to the
`rest` like an index past the prefix.

Reported by the Codex review bot on #1680.

"Exactly one value, `[]`" held for dense arrays only. An array with a hole at
the position reads `undefined` there just as one ending before it does, so it
separates `{ prefix: [number], rest: number }` from
`{ prefix: [], rest: number }` the same way: `[ , 1]` belongs to the second
and not the first. The distinction the guard turns on is "nothing at that
position", not "the array stopped".

Reported by @o2alexanderfedin on #1680.

Replacing the `value.length` test with an entry test lost the bound for a
sparse array: `[1, ,]` has length 2 and one entry, so `{ prefix: [number] }`
accepted it where it had rejected it before, and `array(never)` accepted
`[ , ]`. A hole past the prefix is not an entry, but the array is still that
long, and this is the set `Ts<>` renders as a tuple of exactly `pn` positions
and JSON Schema as `items: false`.

The no-`rest` case now tests both: no undeclared entry, non-index keys
included, and no length past the prefix. A shorter array is unaffected — the
declared loop has already held every position it leaves unfilled to a set
admitting `undefined`.

Reported by the Codex review bot on #1680.