Pacquet's `StoreIndex::set` used `rmp_serde::to_vec_named`, which emits
plain MessagePack maps. pnpm reads `index.db` with
`Packr({useRecords: true, moreTypes: true}).unpack(…)`, and in that
mode every msgpack map at any nesting level decodes as a JS `Map` —
records are the escape hatch that tells msgpackr "this one's a plain
object". So pacquet-written rows came back as a top-level `Map`,
`pkgIndex.files` (a property access) was `undefined`, and pnpm's
`for (const [f, fstat] of pkgIndex.files)` threw
`files is not iterable`.

That surfaced in CI as `ERR_PNPM_READ_FROM_STORE` the first time a
benchmark run hit a shared pnpm-v11 cache that had pacquet-written
rows mixed in — every downstream job's `pnpm install` crashed trying
to decode them. #251 added records *decoding* but the symmetric
write path was wrong: `b0bed43` fixed the `checkedAt` encoding
(float64, not uint64-as-BigInt) and called the interop done, but
never actually round-tripped a pacquet-written row through msgpackr.

## Fix

New `encode_package_files_index` in `msgpackr_records.rs` that emits
msgpackr-records bytes directly:

- `PackageFilesIndex` → record at slot 0x40. `algo` and `files`
  always; `requiresBuild` / `sideEffects` only when `Some`, matching
  msgpackr's field-omit-when-absent convention for plain JS objects.
- `CafsFileInfo` → record at slot 0x41. Fixed `[digest, mode, size,
  checkedAt]` schema so every file in a row shares one slot (msgpackr
  would split shapes across slots; logical decoding is identical
  either way and one slot keeps the encoder simple). `checked_at` is
  `float 64` when `Some`, `nil` when `None` — either maps to pnpm's
  `?? 0` coalesce.
- `SideEffectsDiff` → record at slot 0x42. Fixed `[added, deleted]`.
- `manifest: Some(_)` returns `EncodeError::ManifestNotSupported`
  (pacquet doesn't populate it today; encoding `serde_json::Value`
  records is follow-up work).

The encoder also promotes integer values in `0x40..=0x7f` to `uint 8`
instead of positive fixints. Inside a records stream those bytes are
slot-reference markers, so a bare `0x7b` would be parsed as a ref to
slot 0x7b rather than the integer 123. msgpackr does the same
promotion for the same reason.

`StoreIndex::set` now calls this encoder; `StoreIndex::get` goes
through the existing transcoder which already handled records, so
the read path needed no change beyond updating the doc comment that
still described the old plain-msgpack write path.

## Tests

- Nine new encoder tests in `msgpackr_records::tests`, all using the
  encode → transcode → `rmp_serde::from_slice` round-trip. Covers
  record header emission, slot reuse across many `CafsFileInfo`
  instances, fixint-in-slot-range promotion, nil-for-missing
  checkedAt, optional field inclusion/omission, side effects, and
  the `manifest: Some` error path.
- New `pnpm_reads_pacquet_written_rows` integration test (in
  `crates/cli/tests/pnpm_compatibility.rs`) — this is the end-to-end
  catch: pacquet installs into a store, node_modules is wiped, pnpm
  reinstalls against the same store. If the record encoding is wrong
  this reproduces the benchmark's `ERR_PNPM_READ_FROM_STORE`. The
  existing `same_file_structure` / `same_index_file_contents` tests
  didn't exercise this path because they always cleared the store
  between the pacquet and pnpm halves.

msgpackr_records.rs now carries both directions; update the
module-level doc so `cargo doc` / IDE summaries aren't introducing it
as "Decoder for…" any more. Also spells out both interop failure
modes (pnpm → pacquet and pacquet → pnpm) so a future reader
understands why the write side couldn't just stay on `rmp_serde`.

Both doc blocks still read as if pacquet had only just started
writing msgpackr-records and still mostly writes plain msgpack — the
opposite of the post-PR reality. Rephrase both so:

- `StoreIndex::get` opens with "rows come in three flavours" and
  lists pnpm-written, current-pacquet-written, and legacy-pacquet
  plain-msgpack, in that order.
- The `pnpm_reads_pacquet_written_rows` regression-test header leads
  with the post-PR state ("pacquet now writes msgpackr-records") and
  explains the old encoding as the regression to guard against,
  rather than describing it as the current behaviour.

Previous encoder hardcoded one slot per record type with fixed 4-field
/ 2-field schemas, using `nil` for absent optional fields
(`checkedAt`, `added`, `deleted`). Produced bytes that *decoded* fine
but had a subtly different JS shape than msgpackr's own output —
`{added: Map, deleted: null}` instead of `{added: Map}`, for
instance. pnpm's own readers are nil-tolerant (`?? 0` / truthy
checks), so the actual on-disk effect today is zero, but third-party
tools that inspect the index might not be, and we shouldn't write
bytes that differ from what msgpackr would emit for the same input.

New encoder follows msgpackr's actual strategy (verified against
1.11.8 in the v11 worktree): each distinct **shape** of an inner
record type gets its own slot. A `CafsFileInfo { checked_at: Some }`
gets slot 0x41, `CafsFileInfo { checked_at: None }` gets 0x42,
`SideEffectsDiff { added: Some, deleted: None }` would then get 0x43,
etc. Same-shape instances downstream collapse to a single bare-slot
byte (still the compression win records exist for), while mixed-shape
streams get as many slots as they need without any one slot being
redefined mid-stream.

State:

    struct EncodeState {
        cafs_slots: [Option<u8>; 2],          // indexed by cafs_shape
        side_effects_slots: [Option<u8>; 4],  // indexed by side_effects_shape
        next_slot: u8,
    }

Fixed-size arrays instead of `HashMap` because each record type has at
most 4 possible shapes — a 2-slot `Option<u8>` array is cache-local,
zero-alloc, and measurably faster than `HashMap::get` on the hot
per-file path. The 0x40..=0x7f slot range is 64 entries so we're
nowhere near running out. `allocate_slot` panics if we did, which
would mean >63 distinct record shapes in one stream; not possible for
current pacquet code.

Perf + size unchanged for the common uniform-shape case (every
`CafsFileInfo` has `checkedAt`) — same one def, same N-1 references.
Mixed shapes pay the def cost once per new shape and reuse thereafter,
exactly as msgpackr does. Re-ran the bench: ~2× faster than
`rmp_serde::to_vec_named` and 14% smaller output at 1000 files, same
numbers as the previous iteration within measurement noise.

Tests:

- Renamed `encode_handles_missing_checked_at_as_nil` →
  `encode_omits_checked_at_when_none` and updated the assertion: no
  `checkedAt` field name should appear in the output at all when
  every instance has `None`.
- `encode_allocates_separate_slots_for_distinct_cafs_shapes`: mix
  with/without-`checkedAt` files and assert exactly three record
  defs (outer + the two inner shapes).
- `encode_side_effects_with_only_added_omits_deleted_field`: the
  specific shape Copilot flagged — `SideEffectsDiff { added: Some,
  deleted: None }` must not emit a `deleted` field name.
- `encode_allocates_separate_slots_for_distinct_side_effects_shapes`:
  two `SideEffectsDiff`s with distinct shapes land in separate slots.

`write_nil` is now unused (no more nil-for-absent fields) and removed.

Doc block on `encode_package_files_index` still described the old
fixed-schema implementation: single slot per Rust type, `[digest,
mode, size, checkedAt]` with `nil`, `[added, deleted]` with `nil`.
With shape-aware slot allocation in 9296125, none of that is true
anymore.

Rewrite the **Slot allocation** and **Optional-field handling**
sections so they match the code: `0x40` is fixed for
`PackageFilesIndex`, `0x41..=0x7f` are allocated lazily one-per-shape
in first-seen order, optional fields are omitted from the schema
rather than padded with `nil`. Spell out the pnpm-side consequence —
a `SideEffectsDiff { added: Some, deleted: None }` now decodes to
`{ added: Map }` not `{ added: Map, deleted: null }`.

Also fix the stale `EncodeState::slot_for` link on
`PKG_FILES_INDEX_SLOT` (the helper is `allocate_slot`) and drop the
intra-doc links to the private `cafs_shape` / `side_effects_shape`
fns that were triggering rustdoc private-item warnings.

Two stale-docs follow-ups:

- The encoder rustdoc said pacquet's output is "byte-identical" to
  msgpackr's. Not true — `HashMap` iteration order is
  nondeterministic, so `files` / `sideEffects` / `added` entries
  may be serialised in a different order from msgpackr's JS `Map`
  iteration. Soften to "wire-compatible" (same record schemas, same
  slot numbers, same value encodings; pnpm decodes the same JS
  shape) and explicitly call out that exact bytes can still differ.
- The `same_index_file_contents` test header above
  `pnpm_compatibility.rs` still described pacquet as writing plain
  msgpack via `rmp_serde::to_vec_named`. Rewrite to "both tools
  now write msgpackr records; this test compares post-decode
  structs, not byte-identical rows".

Top-of-file Strategy section said the write side "allocates a slot
per Rust struct type". Not true anymore — a single type can consume
multiple slots when optional-field presence varies, because each
distinct record shape gets its own slot. Reword so the module intro
doesn't imply a 1:1 type↔slot mapping.

`EncodeState::allocate_slot` used `assert!` to guard against running
out of the 0x41..=0x7f inner-slot range. Unreachable today (pacquet
has at most 6 possible record shapes across `CafsFileInfo` and
`SideEffectsDiff`; 63 slots available), but `assert!` panics in
release, which is the wrong failure mode for a corrupted-or-unusual
payload — a typed error gets propagated cleanly up through
`StoreIndex::set` to the caller.

- New `EncodeError::OutOfRecordSlots { max }` variant.
- `allocate_slot` now returns `Result<u8, EncodeError>`.
- Propagated `?` through `encode_cafs_file_info` and
  `encode_side_effects_diff` (both were previously `-> ()`).
- New `allocate_slot_returns_error_past_0x7f` test exhausts the
  inner-slot range directly and asserts the 64th allocation yields
  the typed error rather than panicking.

`encode_pkg_files_index_value` was writing the top-level record
schema as `[algo, files, requiresBuild?, sideEffects?]`, with
optional fields tacked onto the end. The existing
`decodes_requires_build_true` fixture in this same module was
captured from msgpackr 1.11.8 and shows its schema order is
`[algo, requiresBuild, files]` — i.e. msgpackr picks up pnpm's
TypeScript declaration order (`manifest?`, `requiresBuild?`, `algo`,
`files`, `sideEffects?`) as the JS object's insertion order.

Reorder emission to match:

- schema: `[requiresBuild?, algo, files, sideEffects?]` (still
  skipping `manifest` until it's wired through).
- values: same order.

Pnpm decodes either order because records carry field names with
the schema, so this was never a correctness bug — but wire-level
diffing against a pnpm-written reference row is a routine debugging
exercise, and field-order drift makes that harder than it should be.

New `encode_outer_field_order_matches_msgpackr` test decodes the
outer schema's fixstr field-name array out of the encoder's bytes
and asserts `["requiresBuild", "algo", "files"]`, so any future
schema drift trips it.

Two real catches from the reviewer, plus one preemptive fix:

1. Outer field order was wrong again. My previous "fix" put
   `requiresBuild` *before* `algo`, but the
   `decodes_requires_build_true` fixture right here in the module
   shows msgpackr actually emits `[algo, requiresBuild, files]` —
   `requiresBuild` goes **between** `algo` and `files`, not at the
   start. (The `decodes_side_effects` fixture corroborates the
   corresponding `sideEffects` position after `files`.) Fix the
   schema + value order to `[algo, requiresBuild?, files,
   sideEffects?]` and update
   `encode_outer_field_order_matches_msgpackr` to match.
2. `write_array_header`, `write_map_header`, `write_str` all cast
   a `usize` length to `u32` unconditionally when emitting the 32-
   bit variant. On 64-bit hosts a `usize > u32::MAX` would silently
   truncate to a corrupt length prefix. Swap to
   `u32::try_from(n).expect(...)` so overflow panics with a clear
   message instead. Not reachable for any realistic pacquet
   payload (no tarball ships with 4B+ files), but the silent
   corruption mode is worse than a loud crash if it's ever hit.