fix(assets): a remote reference is inert and a declared size is bounded

Two MAJOR findings of the independent v0.10.0 review, both with the
shipped defaults, both new in 0.10.0. Repros rebuilt as tests first.

- A remote <img src>/xlink:href became a LIVE markdown image link in the
  persisted concept, with the address and query string chosen by whoever
  wrote the document. Extraction opens no socket; a consumer rendering
  the bundle does. Now inert text with the address in a code span,
  pinned by a property over the readers rather than by one string. The
  tier asymmetry (user-upload refuses, trusted-source persisted) went to
  the guard repo with the repro.
- Nothing bounded a declared image size: 9.6 KB of PDF declaring
  3000x3000 grayscale zeros took 83 MB peak RSS, linear in pixels.
  MAX_IMAGE_PIXELS (40 000 000) and MAX_IMAGE_BYTES (256 MiB) are read
  off the corpora (largest measured 18.6 MP on K2, 1.4 MP on R761) and
  checked on what the container declares, before any decompression;
  over them is asset_too_large, counted. The same bound closes the
  inline data: URI, which the review flagged and did not measure.

Also fixed, added by PM to this order: an inline PDF image was named
from id() of a Python object, so two concept files of the reference
corpus differed between builds. It is now named from its position.

R761 unchanged: 50 carried of 50 found, assets diff -rq clean.

Report: docs/2026-09-17-bildestien-0-10-1.md

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

README.md

@@ -299,6 +299,38 @@ in must not read like a bundle of documents that had none.
 text. The pointer block passes the gate like any other body line, and the file
 beside it passes nothing. `log.md` says so on every run that carries one.
 
+**A size CEILING, read off the same corpora (0.10.1).** An image whose
+DECLARED size is over `MAX_IMAGE_PIXELS` (40 000 000 pixels) or
+`MAX_IMAGE_BYTES` (256 MiB of samples) is refused with `asset_too_large`,
+counted like every other refusal, and never decoded. The largest image in the
+43-document reference corpus is 4 515 x 4 128 (18.6 MP) and the largest of
+R761's 109 pictures is 2 072 x 656 (1.4 MP), so the bound is an order of
+magnitude above anything measured.
+
+It exists because a few kilobytes can declare an enormous picture: a 9.6 KB
+PDF declaring 3 000 x 3 000 grayscale zeros took 83 MB of peak RSS, a 63 KB
+one declaring 8 000 x 8 000 took 276 MB, and the cost is linear in the pixel
+count, so one document could take a whole batch build with it — before any
+gate, because the guard never sees image bytes. The bound is checked on what
+the container declares, before anything is decompressed, on the two paths that
+decode: a PDF image's raw samples and an inline `data:` URI. An image file
+carried verbatim is not decoded at all, so its cost is its own file size.
+
+<!-- asset-max-pixels: 40000000 -->
+
+**A remote reference is INERT (0.10.1).** `<img src="https://...">` and an STS
+`xlink:href` to an address off this machine are written as text with the
+address in a code span, never as `![...](https://...)`. Extraction opens no
+socket, but a markdown renderer or an agent that fetches what it renders does,
+which would turn "this bundle was opened" into a beacon to whoever wrote the
+document. The address is still stated, because a reader has to know what stood
+there.
+
+**`images: N` in a concept counts POINTER BLOCKS, not unique pictures.** One
+image referenced twelve times in one concept is `images: 12` and one file in
+`assets/`. The key is a count of the places a picture stands, and dedup is on
+content.
+
 **No size floor, and that is a measurement too.** The obvious filter is "ignore
 anything under N pixels", and the distribution offers no N: over the 4 828
 image objects in that corpus, 149 declare no size, 162 are under 32x32, 92