Connected image chunks silently dropped in assemble_retrieval_results

[EricNGOntos]

Problem

In packages/shared-python/shared/services/retrieval/hydration/result_assembly.py, image chunks referenced by text chunks via connect_to metadata are silently dropped from retrieval results.

Root Cause

1. Line 46-50: All chunks referenced via connect_to are marked as embedded_targets and excluded from the final results list (line 54: if row.get('chunk_id') in embedded_targets: continue)

2. Line 71: When assembling text chunk content, only table type targets are inlined:

   if normalize_chunk_type(target_row.get('chunk_type')) != 'table':
       continue  # images are skipped here

This means connected images are:

• Excluded from the results array (treated as "embedded")
• Never actually embedded/inlined into the parent text content

Impact

• Affected paths: _run_classic_topk_route (new) and _try_run_small_corpus_route (existing, runs in production daily)
• Not affected: Agentic route — the evidence renderer (agentic/evidence/renderer.py) has its own image handling that correctly inlines [Image: {asset_url}]\n{description}
• Standalone image chunks (not referenced by any text via connect_to) are unaffected — they appear in results with correct asset_url

Suggested Fix

In assemble_retrieval_results, when processing text chunks' connected targets, add handling for image type alongside table:

if normalize_chunk_type(target_row.get('chunk_type')) == 'table':
    # existing table summary logic
elif normalize_chunk_type(target_row.get('chunk_type')) == 'image':
    # inline image reference: [Image: {asset_url or file_path}]\n{description}

Alternatively, exclude image chunks from embedded_targets so they appear as standalone results with their own asset_url.

[nuemaan]

I'd like to take this. Confirmed the drop against current main:

• result_assembly.py:54 excludes every connect_to target from the results list (embedded_targets).
• result_assembly.py:71 then inlines only table targets into the parent text; the != 'table': continue means image targets fall through and are never inlined. So a connected image is dropped from both places, exactly as described.

Of the two fixes in the issue, I'd go with option 1 (inline the image into the parent text) rather than option 2 (surface as standalone), because it keeps the classic/small-corpus routes consistent with the agentic route. The agentic renderer already inlines images as [Image: {display_ref}]\n{image_description} with display_ref = asset_url or file_path (agentic/evidence/renderer.py:196). Matching that format avoids two divergent image representations across routes.

Concrete shape:

1. Add an _image_inline_content(row) helper mirroring _table_summary_content / _table_display_ref, producing [Image: {asset_url|file_path}] followed by the image description (the image chunk's content, stripped of any self-referential ref the agentic path already strips at line 191).
2. In the text branch, replace the table-only gate with a dispatch: table → existing summary, image → the new helper. Keep the sort_order ordering so multiple connected assets stay stable.
3. Leave embedded_targets semantics unchanged so connected images still don't appear as duplicate standalone rows (they're now represented inline instead).

Tests: extend the retrieval assembly coverage (currently exercised via apps/worker/tests/contract/test_page_memory_retrieval_contract.py) with a text chunk that connects to one image target, asserting the image ref + description land in the parent content and the image is not emitted as a separate result. I'll add a focused unit test for _image_inline_content too.

One scope check before I open a draft: for a connected image with no asset_url/file_path and no description, should the parent still get an empty [Image] marker (parallels the table path's [Table] fallback at line 109), or should that degenerate case be skipped entirely? I lean toward skipping so we don't inject empty markers, but the table path keeps them, so I want to match whatever you prefer for consistency.

If you would rather surface images as standalone results instead, say so and I will take that route.