Decode NI .prj / .usr (Jet) databases via ewd

ewd now handles two kinds of container, with the right decoder picked
by reading the file's magic bytes:

  - compressed-xml (.ewprj, .ms10..ms19): existing PKWare path, writes
    `<file>.xml`.
  - mdb (.prj, .usr): Jet 3 / Jet 4 Access database read via mdb-reader,
    writes `<file>.json` containing every table as `{ columns, rows }`
    with rows as objects. Dates become ISO 8601 strings; OLE/binary
    columns become `{ "_bytes": "base64", "value": "..." }` envelopes
    so the data survives a round-trip.

Mechanism:

  - `src/formats.ts` gained a `kind: 'compressed-xml' | 'mdb'` field on
    each entry, plus a `detectFileFormat(filename)` that opens the file
    briefly and reads the magic bytes.
  - The `mdb` entry's header is `\x00\x01\x00\x00Standard Jet DB` so
    `detectFormatByHeader` matches by content; non-printable bytes are
    escaped in `knownFormatsList()` output.
  - `src/ewd.ts` now dispatches on `format.kind` after detection.
  - `src/decode.ts` adds a defensive kind check (rejects non-cxml).
  - `src/encode.ts` throws a clear "not implemented yet" error when
    asked to encode an mdb format. In-place-edit-only encoding is the
    planned follow-up.

Tests:

  - +18 new tests (61 total) covering Jet magic detection (including
    both Jet 3 and Jet 4 version bytes), on-disk `detectFileFormat`,
    `.prj`/`.usr` extension mapping, the new `kind` discriminator, and
    `normalizeValue` for Date / Uint8Array / Buffer / Buffer-like /
    bigint inputs.

Verified end-to-end on a real `Stocked.prj` (NI Cpcomp_s.prj derivative,
241 components, 37 tables) — decode succeeds and writes a 7 MB JSON.

Adds `mdb-reader` (~106 KB unpacked).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Author: cinderblock

README.md

@@ -1,37 +1,78 @@
 # Electronics Workbench Decoder and Encoder
 
-Two CLIs:
+Interop tools for Electronics Workbench / Multisim / Ultiboard binary
+formats. The goal: get designs and part databases out of EW into
+mainstream representations (and back, where the format permits).
 
-- **`ewd`** — decode an EWB project into its underlying XML.
-- **`ewe`** — encode XML back into a compressed EWB file the original software can re-open.
+- **`ewd`** — decode an EW file into JSON or XML, picking the right
+  decoder by reading the file's magic bytes.
+- **`ewe`** — encode the text-form back into an EW binary the original
+  software can re-open. Currently supports compressed-XML; `.prj` Jet
+  database encode is deferred (see below).
 
 ## Supported formats
 
-| Key        | Extension(s)          | Header                                  |
-| ---------- | --------------------- | --------------------------------------- |
-| `ewprj`    | `.ewprj`              | `CompressedElectronicsWorkbenchXML`     |
-| `multisim` | `.ms10` … `.ms19`     | `MSMCompressedElectronicsWorkbenchXML`  |
+| Key        | Extension(s)       | Kind             | Decode output    |
+| ---------- | ------------------ | ---------------- | ---------------- |
+| `ewprj`    | `.ewprj`           | `compressed-xml` | `<file>.xml`     |
+| `multisim` | `.ms10` … `.ms19`  | `compressed-xml` | `<file>.xml`     |
+| `mdb`      | `.prj`, `.usr`     | `mdb`            | `<file>.json`    |
 
-`ewd` identifies the format by reading the magic bytes at the start of the
-file, so the filename extension can be anything (renamed files, no extension,
-`.dat`, etc. all decode correctly).
+### compressed-xml (`ewprj`, `multisim`)
+
+PKWare DCL Implode (ASCII literal mode, large dictionary) wrapped in a
+small container: a magic-string header, a 64-bit LE total decompressed
+length, then a sequence of `(decompressed_length: u32,
+compressed_length: u32, pkware_implode_block)` sections. Multisim chunks
+big files into 900 000-decompressed-byte sections; `ewe` mirrors that.
+
+Decode and encode are both supported. A decode/encode/decode round-trip
+on every sample tested produces byte-identical XML, and the resulting
+files are accepted by `ewd`.
+
+### mdb (`.prj`, `.usr`)
+
+NI ships part libraries and project component databases as Microsoft
+Access Jet 3 / Jet 4 files (despite the `.prj` / `.usr` extensions).
+`ewd` reads them via [`mdb-reader`](https://www.npmjs.com/package/mdb-reader)
+and emits a single JSON document with every table:
+
+```json
+{
+  "format": "mdb",
+  "source": "Stocked.prj",
+  "tables": {
+    "SYS_COMPONENT": {
+      "columns": [{ "name": "Component_ID", "type": "long" }, ...],
+      "rows": [{ "Component_ID": 17, "Component_Name": "BD9763FVM", ... }, ...]
+    },
+    ...
+  }
+}
+```
+
+Dates become ISO 8601 strings; binary blob fields (`ole` columns) become
+`{ "_bytes": "base64", "value": "..." }` envelopes so the data survives a
+JSON round-trip.
+
+**Encode (write-back) is not implemented yet.** Writing a valid Jet 3
+file from scratch would mean reimplementing Access's page/B-tree storage
+engine, which is a multi-month undertaking. The planned path is in-place
+edits only: read an existing `.prj`, change cell values that fit in the
+existing page layout, write back. That's tractable; a full Jet writer
+is not.
+
+## Format detection
+
+`ewd` identifies the format by reading the magic bytes at the start of
+the file, so the filename extension can be anything (renamed files, no
+extension, `.dat`, etc.). It then dispatches to the right decoder.
 
 `ewe` infers the format from the **output** filename's extension; pass
 `--format <key>` to override for non-standard extensions. Out-of-range
 Multisim versions (e.g. `.ms9` or future `.ms20+`) need an explicit
 `--format multisim`.
 
-The container is a small header, then a 64-bit little-endian total
-decompressed length, then a sequence of `(decompressed_length: u32,
-compressed_length: u32, pkware_implode_block)` sections. Compression is
-PKWare DCL Implode (ASCII literal mode, large dictionary). Multisim chunks
-big files into 900 000-decompressed-byte sections; `ewe` mirrors that.
-
-> Note: the `*.prj` / `*.usr` / `*.ldb` files that ship as part of NI's
-> "Electronics Workbench Database" are Microsoft Access (Jet) databases,
-> not the compressed-XML container described here. They aren't handled by
-> `ewd` / `ewe`.
-
 ## Install
 
 Requires [bun](https://bun.sh) (≥ 1.0).
@@ -44,9 +85,11 @@ bun install
 
 ```bash
 bun run ewd --verbose ./samples/Temp.ewprj ./samples/Design1.ms14
+bun run ewd --verbose ./samples/Stocked.prj          # writes Stocked.prj.json
 ```
 
-For each input, writes `<filename>.xml` next to it.
+For each input, writes `<filename>.xml` (compressed-xml) or
+`<filename>.json` (mdb) next to it.
 
 Options:
 
@@ -75,6 +118,9 @@ Options:
 - `-f`, `--format <key>` — force a format (`ewprj` or `multisim`)
 - positional args — XML files to encode
 
+Trying to encode an `mdb` target fails with a clear error until
+in-place-edit support lands.
+
 ### Compression ratio caveat
 
 `ewe` uses [`node-pkware`](https://github.com/cinderblock/node-pkware)'s
@@ -91,10 +137,12 @@ produces byte-identical XML, and the resulting files are accepted by
 bun test
 ```
 
-Covers the format registry (extension matching, header detection),
-encoder filename helpers, and round-trip integration tests (tiny
-`.ewprj`, tiny `.ms14`, multi-block payload that spans more than one
-PKWare section, and an empty payload).
+Covers the format registry (extension matching, header detection
+including the Jet magic prefix with leading NUL bytes, on-disk
+detection), encoder filename helpers, `mdb` value normalization
+(`Date` → ISO, OLE blobs → base64), and compressed-xml round-trip
+integration (tiny `.ewprj`, tiny `.ms14`, multi-block payload that
+spans more than one PKWare section, and an empty payload).
 
 ## Development