ocda: ST_DocHas from a loaded abstraction

docHasFromAbstraction() builds ST_DocHas from the objects and the
@doc_has block, so a document read from a .ssp or a .ocda.db can reach
the value the parser reaches. Everything it builds is an index over
properties the artefact already carries, not a recomputation of
something it does not: the counts come from the header, imagelist from
the .image records, the segment name lists and the tag associations from
.anchor, .segment, .segment_epub, .heading_lev_anchor and
.segment_*_is, and section_keys_sequenced from which sections are
non-empty plus the run's own flags.

*The two defect fixes this now sits on did most of the closing.*
Measured before them and after, over some 30,000 tag_associations
entries and the 1,651 keys a document actually links to:

  imagelist        8 documents differed, now none. The parser was
                   the one that was wrong, and rgx.image being
                   anchored to image markup brought it into line
                   with what the .image records always said.
  key sets         four keys differed (_part_eof, "0", the empty
                   key, and "toc" the other way about), now none.
                   _part_eof came back the moment @tail was
                   carried, and the rest with it.
  values           89 link targets resolved differently, now 1.

The one left is free_culture's ocn 5, and it is the case this cannot
reach: a heading above level 4 takes its segment by back-filling when
the next level 4 heading arrives, so the object never holds the answer
and reading the objects in order only approximates it. Fixed properly in
the commit that follows, in ocda where the field is made, rather than
guessed at here.

(assisted by Claude-Code)

0 files changed, 0 insertions, 0 deletions