[KennyMcSimpson]

A partial DataView is restored over its entire backing buffer instead of keeping its original range. For new DataView(Uint8Array.from([10, 20, 30, 40]).buffer, 1, 2), the restored view should expose [20, 30] at offset 1 with length 2.

Serialize every DataView as a two-element type/value record with a fixed literal payload:

['DataView', {buffer: [10, 20, 30, 40], byteOffset: 1, byteLength: 2}]

The named fields preserve the API's type/value pair contract and avoid inferring view geometry from optional trailing array elements. Regenerate CommonJS and the browser bundle. The reader also accepts legacy ['DataView', bytes] records, including an empty buffer.

Fixes #28.

Validation on Windows with Node 24.11.0:

• npm ci and npm run build pass; the complete test suite reports 100% statement, branch, function and line coverage.
• Regressions cover partial, full and zero-length views, read bounds, source-buffer independence, the two-element record contract and legacy records.
• An independent native-reference check passes for all 969 valid view layouts over buffers of size 0–16 across nine CommonJS, ESM, forced-polyfill and browser-bundle routes: 8,721 round-trip comparisons and 51 legacy-record reads.
• git diff --check passes. The bundle is evaluated in an isolated JavaScript context; no browser-version matrix was run.

Compatibility: the reader retains support for old records. The DataView wire encoding now uses the named payload for full views too; older readers do not support that payload. Repeated-reference handling in #29 remains a separate change.

AI assistance: prepared and validated with OpenAI Codex.

[WebReflection]

The engine de-optimizes on potentially missing details ... I took a stretch for length 1 VS length 2 here but ideally I don't like "blind guessing" over arrays so that while I like this approach, and I've used the same in flatted-view which is way more superior than this but nobody talks about it, me included, I think the as(entry, value) should have value as a literal that can be deserialized without breaking the potential [key, value] pair contract this whole API works around ... because there could be future changes and [, , what, ever] or [, , , , what ever] does not look like a great path forward.

As summary: could we have a properly typed literal shape that describe fields instead of lurking the amount of indexes in the array? That'd be awesome and, if we cannot for other reasons I don't remember, I'd be OK moving this edge case forward, thanks.