`wafflebase docs export <id> <file>` previously called `exportPdf`
and `exportDocx` with no `imageFetcher`, so any document containing
even one image inline rejected the export with:

  imageFetcher required: document contains 1 image inline(s);
  first: https://api.wafflebase.io/images/<uuid>.png

That guard lives in `pdf-image-painter.ts` (and a sibling check in
`docx-exporter.ts`) and is intentional — silently dropping image
content would change the visible output without warning. The CLI
just never built a fetcher.

Add `createImageFetcher({ serverBase })` that mirrors the frontend's
`docsImageFetcher`: absolute URLs (`http(s):`, `data:`, `blob:`,
`file:`) pass through untouched, and server-relative paths
(`/images/<id>`) resolve against the CLI's configured server. The
backend `GET /images/:id` route is publicly readable so no auth
header is needed; the fetcher returns a `Blob` the exporter embeds
directly.

Plumb the fetcher into `CliPdfExportOptions.imageFetcher`,
`CliDocxExportOptions.imageFetcher` (already supported), and the
`docs export` action so both PDF and DOCX paths get one for free.

Tests:
- New `image-fetcher.test.ts` covers URL resolution rules and the
  fetcher's success/error mapping with an injected fetch stub.
- `docs-export.test.ts` adds a regression test that reproduces the
  reported error message verbatim, plus an embed test that exercises
  the full PDF pipeline with a 1×1 PNG stub fetcher. The DOCX
  symmetric regression is deliberately not duplicated here because a
  failing `DocxExporter.export` invocation perturbs JSZip's Blob
  support state in pure-Node tests; that path is already covered in
  the docs package's jsdom-env suite.