ocda db: rows for repeatable fields & images inside

Four things in the abstraction are open ended lists that a single
row cannot hold, and which the database therefore could not
express at all: a paragraph's extracted links, its anchor tags, a
heading's lev4 subtoc entries, and the image records. Each now has
a table keyed on the object, ordered by seq:

  object_images, object_links, object_anchors, object_subtoc

And the images themselves are carried in the file, in a files
table with role, name, bytes, sha256, pixel size and the blob. The
point is self-sufficiency: html copies every image into its output
tree, epub and odt place them in their zips, and xelatex reads
them from disk, so an abstraction without the bytes cannot produce
a document, only its text and structure. The table is deliberately
generic rather than an images feature, so that the same mechanism
can later carry the source .sst or the pod's configuration by
adding a row with another role, and so that a reader can ask
whether a database carries its images (select count(*) from files
where role='image') and fall back to a directory beside it when
the answer is zero.

Bytes are stored exactly as read and the digest is taken over them.

Only images the document references are carried: the sisu manual's
media/image holds 10 files and 5 are in its image list, so 5 are
stored.

(assisted by Claude-Code)

0 files changed, 0 insertions, 0 deletions