feat: persist RAPTOR layer metadata on summary chunks

[yuch85]

Summary

RAPTOR's recursive clustering builds a layers list tracking (start_idx, end_idx) boundaries per level, but currently discards this information — only the flat chunks list is returned. This makes it impossible to distinguish leaf-level summaries from top-level ones.

This PR:

• Returns (chunks, layers) tuple from raptor.py's __call__
• Annotates each RAPTOR summary chunk with raptor_layer_int (1 = first summary level, 2 = summary-of-summaries, etc.)
• Adds raptor_layer_int to infinity_mapping.json (Elasticsearch handles it via existing *_int dynamic template)

Why this matters

Downstream features need to know which RAPTOR layer a summary belongs to:

• Retrieving the top-level document summary for entity extraction, search snippets, or document comparison
• Filtering by abstraction level — users may want only high-level summaries or only leaf-level cluster summaries
• RAPTOR recall quality — [Question]: RAPTOR-Generated Summary Chunks Not Recalled for Direct Definition Questions #10951 reports summaries not being recalled for definition queries; layer metadata enables targeted retrieval

Changes

File	Change	LOC
rag/raptor.py	Return (chunks, layers) tuple	~3
rag/svr/task_executor.py	Build chunk_layer mapping, set raptor_layer_int	~12
conf/infinity_mapping.json	Add raptor_layer_int integer field	~1

Backward compatibility

• Additive only — no existing fields or behavior changed
• Existing RAPTOR chunks continue to work (they'll have raptor_layer_int = 0 by default)
• New RAPTOR chunks get layer metadata automatically

Test plan

• Parse a document with RAPTOR enabled, verify raptor_layer_int is set on indexed chunks
• Verify raptor_layer_int values increase with abstraction level (layer 1 < layer 2 < ...)
• Verify existing RAPTOR deletion (delete by raptor_kwd) still works
• Verify Infinity backend accepts the new field

Fixes #7488
Related: #4104, #11191, #10951

🤖 Generated with Claude Code