feat: simplify extraction pipeline and add batch entity summarization

[prasmussen15]

Summary

• Remove chunking code for entity-dense episodes and edge extraction - improved LLMs can now handle larger outputs in single calls
• Add batch entity summarization - summarize all entities in a single LLM call instead of one-by-one
• Simplify edge attribute extraction - extract attributes from fact text only (with reference_time), not full episode content
• Improve edge deduplication - continuous indexing, allow duplicate candidates to also be contradicted

Changes

Node Operations

• Remove _extract_nodes_chunked, _extract_from_chunk, _merge_extracted_entities
• Add _extract_entity_summaries_batch for batch summarization
• Nodes with short summaries get edge facts appended directly (no LLM call)

Edge Operations

• Remove MAX_NODES constant and generate_covering_chunks usage
• Process all nodes in single LLM call for edge extraction
• Deduplicate invalidation candidates against duplicate candidates
• Use continuous indexing across both candidate lists

Prompts

• New extract_summaries_batch prompt with SummarizedEntity/SummarizedEntities models
• Simplified extract_attributes for edges (fact + reference_time + existing_attributes only)
• Updated resolve_edge with continuous indexing and consolidated contradicted_facts field

Tests

• Remove obsolete chunking tests from test_entity_extraction.py

Test plan

• Run existing unit tests
• Test entity extraction with large episodes
• Test edge extraction with many nodes
• Test batch summarization with multiple entities
• Verify edge deduplication and contradiction detection

🤖 Generated with Claude Code

[claude]

Token usage is recorded even when there's an exception during retry attempts. The total_input_tokens and total_output_tokens are accumulated across retries, but if a retry fails after a successful initial call, the tracker will record tokens from both the successful and failed attempts, potentially double-counting.

Consider moving the token_tracker.record() call outside the retry loop, or only record on the first successful response.

[claude]

Minor: The docstring says "Thread-safe" but this is an async codebase. While threading.Lock works for protecting shared state in async code (since asyncio is single-threaded), the comments and design suggest this was written with threading in mind.

For clarity and potential future multi-threaded scenarios (e.g., if using ThreadPoolExecutor for blocking operations), this is fine. However, if you want to be more explicit about async-safe design, you could use asyncio.Lock instead, which is specifically designed for async contexts.

That said, threading.Lock is actually safer here if the tracker might be accessed from both sync and async contexts (like from the print_summary method which is sync).