Closes #1208.

The bug

ttessarolo reported a palace with 67,580 drawers silently losing 85% of its data through `mempalace repair`:

```
Drawers found: 10000
...
Repair complete. 10000 drawers rebuilt.
```

Verified by direct SQL: the embeddings table genuinely held 67,580 rows before repair, 10,000 after. ChromaDB's collection-layer `get()` silently caps at 10,000 when reading a collection whose segment metadata is stale — exactly the state you're in after manual HNSW quarantine, which is exactly what the issue reporter had to do to make repair runnable in the first place. `col.count()` returns the same capped value, so the loop bound (`while offset < total`) doesn't catch it.

The fix

Defense-in-depth, not data recovery. Repair now refuses to overwrite when it can't trust the extraction count.

Strong signal — query `chroma.sqlite3` directly via a read-only sqlite3 connection:

```sql
SELECT COUNT(*)
FROM embeddings e
JOIN segments s ON e.segment_id = s.id
JOIN collections c ON s.collection = c.id
WHERE c.name = ?
```

If that count exceeds the extracted count, abort before `delete_collection` runs. The error message names both numbers and the implied data loss percentage.

Weak signal — for chromadb schema drift / locked-file cases where the SQLite query can't run, fall back to: if extracted count equals exactly `CHROMADB_DEFAULT_GET_LIMIT` (10,000), refuse without explicit acknowledgement. Hitting the chromadb default `get()` cap exactly is suspicious enough.

Override — `--confirm-truncation-ok` flag (and `rebuild_index(confirm_truncation_ok=True)` kwarg) for the rare case of a palace legitimately sized at the cap, after independent verification.

Shared between two paths

The guard lives in `repair.check_extraction_safety()` and raises `TruncationDetected` with the printable message. Both call sites use it:

• `cli.py::cmd_repair` — the user-facing `mempalace repair` command (this is the path the bug report hit).
• `repair.py::rebuild_index` — the lower-level entry point used by `python -m mempalace.repair rebuild`.

Same logic, single implementation, identical error wording.

Tests

9 new test cases in `tests/test_repair.py`:

• `test_check_extraction_safety_passes_when_counts_match` — safe path
• `test_check_extraction_safety_passes_when_sqlite_unreadable_and_under_cap` — safe path with weak fallback
• `test_check_extraction_safety_aborts_when_sqlite_higher` — the user's reported case (67,580 vs 10,000)
• `test_check_extraction_safety_aborts_when_unreadable_and_at_cap` — fallback signal fires
• `test_check_extraction_safety_override_skips_check` — override flag works
• `test_sqlite_drawer_count_returns_none_on_missing_file` — graceful degrade
• `test_sqlite_drawer_count_returns_none_on_unreadable_schema` — graceful degrade
• `test_rebuild_index_aborts_on_truncation_signal` — end-to-end: no `delete_collection`, no upsert, no backup written when guard fires
• `test_rebuild_index_proceeds_with_override` — end-to-end: override unblocks the destructive path

Full suite locally: 1317 passed in 35s (+9 from develop @ HEAD baseline).

What's NOT in this PR

Actually recovering the lost 57,580 drawers from the user's case. The rows are still on disk in `chroma.sqlite3.embeddings`; recovery requires bypassing the chromadb collection layer entirely (read embeddings table → re-create segments → re-attach to collection, or extract and re-mine from source). That's a separate flow worth its own design — this PR's job is to stop repair from making it worse.

Refs #1208 and the #1145 / #934 / #1093 incident class generally.