Long-doc (PageIndex) images are extracted but never surface in the rendered wiki

[designcomputer]

Problem

For long documents that route through PageIndex (doc_type: pageindex), images are correctly extracted to wiki/sources/images/<doc_name>/ and referenced with correct wiki-relative paths inside wiki/sources/<doc_name>.json (each page object has "images": [{"path": "sources/images/<doc>/pX_imgY.png"}], and the paths are also inlined as ![image](...) in each page's content).

However, tree_renderer.py's render_summary_md() — which builds wiki/summaries/<doc_name>.md, the actual page a user opens in Obsidian — never reads or embeds any of this. Its per-node renderer (_render_nodes_summary) explicitly strips ![]() syntax found in node["text"] (necessary, since PageIndex's own embedded refs point into a private .openkb/files/{doc_id}/images/... cache that doesn't resolve from the wiki), but never re-inserts the correctly-pathed images that live in the page JSON.

Net effect: images are on disk, and technically "referenced" in a JSON data file, but invisible everywhere a human actually browses the vault — not in the summary, not in any concept/entity page, not in index.md. wiki/sources/<doc_name>.json isn't rendered as a wiki page by Obsidian (or anything else), so those references are effectively inert.

Reproduction

1. openkb add a PDF long enough to trigger PageIndex (pageindex_threshold, default 20 pages), with no PAGEINDEX_API_KEY set (so it falls back to local pymupdf extraction, which does extract images — see images.py:convert_pdf_to_pages).
2. Open the resulting wiki/summaries/<doc>.md in Obsidian, or grep '!\[' wiki/summaries/*.md wiki/concepts/*.md wiki/entities/*.md wiki/index.md.
3. Zero image references anywhere, despite wiki/sources/images/<doc>/ containing real extracted files and wiki/sources/<doc>.json referencing them correctly.

Confirmed on openkb 0.4.2 with a 31-page manual (35 images extracted across 21 pages, 0 surfaced in the summary).

Relation to existing issues

• Feature: Optional image understanding / vision for inline and referenced images #74 is about giving the LLM vision over referenced images during compilation — a different problem (that's about compile-time understanding; this is about images not being visible in the rendered output at all, regardless of whether the LLM ever "saw" them).
• [Feature] Share PDF page extraction across short PDFs and long PDF page JSON #135 is about unifying the PDF extraction backend between short/long paths — doesn't touch the summary-rendering gap described here.

Suggested fix

_write_long_doc_artifacts in indexer.py already has the per-page pages list (with images) in scope when it calls render_summary_md — it's just not passed through. render_summary_md/_render_nodes_summary could accept that list, build a page_num -> [image paths] map, and embed each node's page-range images inline (tracking already-emitted paths the same way duplicate summaries are already collapsed, so a page split across many sibling nodes doesn't repeat the same figure at every one of them).

Happy to share a working patch/diff if useful — implemented and verified this locally against a real ingest (35/35 images now appear in the rendered summary, none duplicated across sibling nodes on the same page).

[designcomputer]

Opened a fix for this specifically: #170 (embeds each node's page-range images inline, closes this issue on merge).

While investigating this, found and fixed three other quality issues in the same renderer for doc_type: pageindex long docs — submitted as separate PRs since they're independent, non-overlapping fixes to the same function:

• fix(tree_renderer): truncate overlong node titles in summary headings #167 — overlong node titles (full source sentences copied verbatim) are now truncated for the heading
• fix(tree_renderer): render real per-node source text, not just the summary #168 — real per-node source text is now rendered, not just an LLM paraphrase (the renderer was silently discarding text that indexer.py already fetches)
• fix(tree_renderer): collapse duplicate sibling/cousin summaries #169 — duplicate summaries across sibling/cousin nodes on the same physical page now collapse to a pointer instead of repeating verbatim

All four came out of the same investigation into a real long-document ingest, so flagging them together here in case they're useful context for review.