The §3 ownership scan globbed every *.md file regardless of which door
wrote it, then unconditionally unlinked whatever _is_ingest_owned agreed
to. Because _is_ingest_owned reads through the line-oriented parser that
flattens nested blocks (pinned in
test_two_nested_block_mappings_sharing_a_key_collide_in_the_scalar_parser),
a Door B/C file whose nested content happened to share a key name with
the ownership markers (generated, ingest_manifest) could get promoted to
top level and spoof ownership -- silently deleting content this door
never wrote.
Scoping the glob to ingest_prefix closes this by construction: a Door
B/C file is never even a candidate for the scan, regardless of what its
frontmatter parses to. Traced from a coordination tip from
portfolio-optimiser-claude about the same flattening mechanism hitting
their `type` field.
Kjell Tore Guttormsen
7c608bed1a