Set up a TECH_DEBT.md ledger Claude Code appends to instead of fixing things on the sly

Set up TECH_DEBT.md at the repository root and establish the rule Claude Code follows around it from now on: when work in the ingestion pipeline (rag/loaders/ and rag/chunking/) surfaces something that is technical debt — not a bug, not a missing feature, but a shortcut, an outdated pattern, or a known-fragile piece of code — it gets logged here, not silently fixed as a side effect of whatever task happens to be touching it nearby.

For an initial pass, scan the ingestion pipeline (rag/loaders/ and rag/chunking/) now and populate the ledger with what you find, one row per item:

| Item | Location | Severity | Effort | Why it matters |

- Location must be an actual file and line or function, not a vague area description — an item nobody can find again by reading the ledger is not tracked, it is just noted.
- Severity and effort are scored using this rubric: Severity: low/medium/high based on blast radius if it fails in production; Effort: hours estimate assuming one engineer familiar with this module. Score both independently; a high-severity item can still be low-effort to fix, and conflating the two is how a ledger ends up ranked by how scary something sounds rather than by what should actually be worked on next.
- 'Why it matters' is one sentence stating the concrete consequence if this stays unfixed — a slow query under real load, a silent data-corruption edge case, a dependency past end-of-life — not a generic 'this is bad practice.'

If a ledger already exists at docs/TECH_DEBT.md (last updated three months ago, seven open items), read it first and merge into it rather than starting a second, competing list — reconcile any item that appears in both, and mark anything the existing ledger lists as fixed that this scan can now confirm is actually resolved in the current code.

PRIORITIZATION
At the end of the ledger, order items by highest severity first, then lowest effort as a tiebreaker, so cheap high-severity fixes surface at the very top, and state the ordering rule explicitly at the top of that section so a future session extending the list applies the same rule rather than inventing a new ordering.

RULE GOING FORWARD
When future work touches code near a logged debt item but the current task does not actually require fixing it, leave it alone and leave the ledger entry as is — do not fix it silently because you happen to be right there. If the current task's own scope genuinely requires touching the debt item to complete correctly, fix it, then update its ledger row to fixed with the commit reference, rather than leaving a now-inaccurate row for the next session to trip over.

Do not log anything here that is actually a bug (something already broken now) or a feature gap (something that was never built) — both belong in the issue tracker, not this ledger; TECH_DEBT.md is only for working code that is more fragile, harder to change, or costlier to run than it should be.