v0.8.11 — Restore: updated_at erhalten, Embedding-Backfill gechunkt

Beide Bugs fielen beim Neuaufbau der Prod-DB aus einem Backup auf (139 MB Write-Bloat → 10,8 MB).

updated_at überlebt den Restore. _apply_import schrieb created_at in beide Zeitstempel und verwarf das exportierte updated_at. Ein Restore setzte damit die Recency-Info aller je geänderten Entities zurück (256 von 524) und verfälschte die updated_at-Sortierung in memory_get_context.

Embedding-Backfill läuft gechunkt. _embed_backfill embeddete alle Entities in einem einzigen _embed_texts-Call. Im Normalbetrieb unauffällig — es sind nie viele Vektoren offen —, nach einem Restore aber tödlich: 524 Texte plus Modell sprengten mem_limit=1536m, der Container starb ohne Traceback im Restart-Loop. Mit höherem Limit lief er danach in „buffer pool is full", weil Kuzu die Dirty-Pages der Writes bis zum Checkpoint im Pool hält. Chunking allein reichte nicht (Abbruch bei 288/524) — der Checkpoint je Chunk braucht force=True, da die WAL unter KUZU_WAL_CHECKPOINT_MB bleibt und der größenbasierte Check sonst ein No-op ist.

Neue Env: EMBED_BACKFILL_CHUNK (Default 32). Abgebrochene Läufe verlieren nichts — geschriebene Chunks bleiben, der nächste Lauf macht am offenen Rest weiter.

Verifiziert unter Prod-Limits (1536m, Buffer-Pool 256 MB): Restore von 524 Entities + 422 Relationen inklusive Vollbackfill läuft in einem Durchgang durch, Peak ~1,0 GiB. Beide Regressionstests schlagen gegen den alten Stand fehl.

PR: #68