dump: in-cell images are serialized as literal "[image]" text — support base64 round-trip

## Background

The `dump` command's replayable batch script is a great fit for a template-as-code workflow: keep the template as a plain-text script under version control, then rebuild the workbook with `create` + `batch`. We tested this end-to-end on **v1.0.139 (win-x64)** with a real report template (styled headers, merged title, number formats, borders, a formula, and one in-cell image), and the fidelity is excellent — after a full `dump /` → `create` + `batch` round-trip, `styles.xml` is identical and `sheet1.xml` is byte-for-byte identical *except* for the image cell.

That image cell is the one remaining gap.

## Current behavior (observed on v1.0.139)

Given a workbook where `C3` carries an in-cell image (set via `--prop image=` per #239), `dump /` serializes the cell as the literal text `[image]` inside the `import` data block:

```json
{"command":"import","parent":"/Sheet1","props":{"start-cell":"A1"},
"text":"Monthly Report\nItem,Value,Photo\nTotal hours,1234.5,[image]\nHeadcount,57\n,=SUM(B3:B4)\n"}
```

There is no `image=` instruction anywhere in the dump output, and the alt text is lost as well.

Replaying that script consequently produces a workbook with no image:

- Missing parts: `xl/media/*`, `xl/richData/*` (rdrichvalue, rdrichvaluestructure, rdRichValueTypes), `xl/metadata1.xml`
- The cell degrades from a richValue to a plain string:

```xml

#VALUE!

[image]
```

## Repro steps

```bash
officecli create template.xlsx
officecli batch template.xlsx build.json # includes: {"command":"set","path":"/Sheet1/C3","props":{"image":"photo.png","alt":"Site photo"}}
officecli batch template.xlsx dump.json # [{"command":"dump","path":"/"}] -> dump output
officecli create replayed.xlsx
officecli batch replayed.xlsx # image is gone; C3 contains the string "[image]"
```

## Proposal

Have `dump` serialize in-cell images with the actual image bytes embedded as base64, so a single dump script is a complete, self-contained template. The exact shape is of course your call — e.g.:

- `"image": "base64:iVBORw0KGgo..."`, or
- a data URI (`data:image/png;base64,...`), or
- a separate field alongside the emitted `set` command.

The `alt` text should be preserved in the same instruction. If floating pictures (`add --type picture`) have a similar serialization gap, it may be worth covering them in the same design — we have not tested that side, so no claim there.

## Relation to #239

Same template-as-code workflow: #239 solved the write side (setting in-cell images from a batch script, which we verified works great in v1.0.139). This request is about the serialization side — making `dump` emit what `set --prop image=` can now consume — which would close the loop and make dump scripts fully round-trip-safe for image-bearing templates.

Start with the dump command and the batch replay flow, using the provided create → batch → dump → replay reproduction with the image at /Sheet1/C3. Inspect how image cells become "[image]" and how set --prop image= consumes data, then verify that the dumped instruction preserves image bytes and alt text and restores xl/media, xl/richData, and xl/metadata1.xml.

Written by the indexing model from the issue text.