No byte cap on stored LLM request/response payloads, and the log prune job never VACUUMs

Two compounding storage issues surfaced by the 3 Oct runaway-loop incident (assistant-logs.db reached 6.80 GB; a manual VACUUM took it to 4.3 MB — 99.9% reclaimable). 1. No byte cap on stored LLM request/response bodies. persistence/llm-request-log-store.ts stores the full request and response payloads. The only references to their size are metadata reads (row.requestPayload.length at :230, row.responsePayload.length at :231) — nothing bounds what is written. During the incident each of the 3,802 loop iterations logged its full, growing context: payloads went from ~0.2 MB to ~2.1 MB per call, ~750 MB/hour into the DB. 2. The prune job never VACUUMs. persistence/job-handlers/cleanup.ts deletes rows by created_at cutoff (`DELETE FROM llm_request_logs WHERE created_at < ...`, PRUNE_LOG_BATCH_LIMIT = 1000) but never runs VACUUM afterwards. Deleted bytes therefore never leave the file — the DB holds its high-water mark forever. There is no reason for the file to sit at 1,600x its live size. Requested fixes: (a) truncate stored request/response bodies above a byte cap (or store a hash + first/last N KB); (b) run an incremental VACUUM (or auto_vacuum) after prune batches so reclaimed space is actually returned. Both are hygiene rather than root cause — Bugs 1 and 2 are what allowed the incident — but without (a) and (b) any future log-heavy incident leaves a multi-GB file behind permanently.