Make a bundle reopenable, and number slices

A bundle was a one-way trip. The slice images are output and the cuts
that produced them lived only in the producer's own project file, so a
bundle someone handed you meant cutting the score again from scratch.

The manifest now carries the geometry, in a `source` block: per page the
cut polylines, skew, levels and content rectangle, all in normalised
coordinates so they survive any render resolution, and per slice the page
and slot it came from. Discards are stated by omission — a slot no slice
claims was discarded — since shipping a discarded slice's image would
defeat discarding it.

`noteman-slicer open song.zip` unpacks the archived PDF, rebuilds the
project from that geometry, restores markers, engravings and the title
block, and opens the editor. Jump destinations go back from an array
index to the (page, slot) the editor works in. The images in the zip are
discarded: the PDF is what the pipeline renders from. Re-exporting a
reopened bundle reproduces its manifest exactly. It refuses to overwrite
a PDF or project file already sitting there, because the obvious place to
unpack is where someone's unfinished cuts live.

Separately, every slice can now carry the measure it starts at, not just
a re-engraved one — a scanned system is numbered in the score the same
way, and noteman wants to answer "take it from bar 33" about either. It
moves off the replacement onto the page, alongside markers and discards,
and out of the bundle's engraving object onto the slice.

docs/spec.md

@@ -347,6 +347,15 @@ slice they sit on, so indices appear in exactly one place: a jump source's
 MP3s are planned for a later phase, and bundles are archived artifacts that may be
 re-imported a year later.
 
+The manifest also carries the cuts, in a `source` block: the polylines, skew,
+levels and content rectangle per page, and the page and slot each slice came
+from. That is what makes `noteman-slicer open song.zip` a real round trip rather
+than a re-detection that happens to land nearby — it unpacks the archived PDF,
+rebuilds the project from the geometry, and re-renders. The images in the zip
+are output and are discarded on the way back in. Slots no slice claims were the
+discarded ones; a bundle states that by omission, since shipping a discarded
+slice's image would defeat discarding it.
+
 Otherwise: plain zip, no manifest beyond this, no checksums, hand-fixable.
 Python's `zipfile` is stdlib; the import side needs one zero-dep library
 (`fflate`), since Bun has zlib but no zip reader.