Every tracked path resolves on disk (case-insensitively), working tree is clean, and

core.ignorecase=true

. So there's no actual broken orphan causing problems right now — the 158/157 is just git tracking one extra case-variant name that resolves to an existing inode, and with

ignorecase=true

git treats it as clean. The real question: is there a duplicate page pair in the index? Earlier the import logged warnings like "shares content_hash with meetings/...-evr6op but has different frontmatter.id — Indexing both." That means the index has both a mixed-case-slug page and a lowercase-slug page for the same content. Let me check the