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/guide.md

@@ -53,6 +53,14 @@ off.
 Page Up / Page Down move between pages. Levels carry over from the previous
 page, so a consistent scan only needs setting once.
 
+## Bar numbers
+
+Under *This slice*, **First bar** is the measure that slice starts at, as the
+score numbers it. Optional, and only worth filling in where the printed score
+shows a number — that is what lets noteman answer "take it from bar 33". A
+re-engraved slice prints the number above its first bar, exactly as the scanned
+systems around it do.
+
 ## Markers
 
 Markers are the navigation symbols noteman uses to jump around the score:
@@ -93,6 +101,22 @@ Two things worth knowing:
   detection rather than resuming decisions that already shipped. If you really
   want the old cuts back, `noteman-slicer edit my-song.pdf --resume`.
 
+## Reopening a bundle
+
+```
+noteman-slicer open my-song.zip
+```
+
+Unpacks the archived PDF beside the bundle, rebuilds the project from it — the
+cuts, skew, levels, discards, markers, title block and any re-engraved systems —
+and opens the editor on it. Everything you changed re-renders from the PDF; the
+slice images in the zip are output and are thrown away.
+
+This works on any bundle, not just one you made: the cuts travel in `song.json`.
+It refuses to overwrite a PDF or project file that is already there, since the
+obvious place to unpack is exactly where someone's unfinished work lives — pass
+`--pdf elsewhere.pdf` or `--force` if you mean it.
+
 ## Re-engraving a slice (optional, needs LilyPond)
 
 When a system is beyond rescue — a bad scan, a wrong transposition, a passage
@@ -142,6 +166,8 @@ noteman-slicer info my-song.pdf        # source type and page rasters
 noteman-slicer detect my-song.pdf      # detection results + debug overlays
 noteman-slicer project my-song.pdf     # what the project file currently holds
 noteman-slicer export my-song.pdf      # export without opening the editor
+noteman-slicer open my-song.zip        # unpack a bundle; --no-edit to stop there
 ```
 
-Every command takes `--type raster|vector` to override source-type detection.
+Every command that takes a PDF takes `--type raster|vector` to override
+source-type detection.