Reduce activity-write and observability overhead

[ronak-guliani]

Summary

Reduce SQLite write amplification, background cleanup bursts, and aggregate provider-log growth while preserving ordered activity delivery.

Problem

The reported profile contains 9,204 activity appends in the latest 10,000 events. Tool lifecycle appends currently commit individually, and per-thread provider-log rotation does not constrain total disk usage across old threads. Cleanup recovery sweeps can also enqueue every due job at once.

Solution

• ProviderRuntimeIngestion now enqueues tool activity commands without awaiting each commit, so its serialized event worker can feed the engine's FIFO batch window. Source-event acknowledgement and checkpoint handoff wait for the activity tickets to commit. The engine batches only contiguous, same-thread tool.started, tool.updated, and tool.completed appends (up to 32); errors, approvals, and turn/message completion boundaries remain immediate. Failed batches fall back to individual dispatch.
• Cap provider logs globally at 1 GiB and 30 days, disable timing traces by default, and retain a deterministic 10% sample of successful SQL spans while keeping failures.
• Limit each worktree-cleanup recovery sweep to 16 due jobs and add a partial index for the due-job query.
• The fork already has the 32 MiB WAL limit and has removed two redundant projection indexes. Remaining upstream index candidates differ from this fork's schema and were not dropped without query-plan evidence. See upstream WAL fix #13684 and index cleanup #12847.

Validation: formatting, lint, typecheck, and provider lifecycle tests pass. The producer-path regression test verifies six serialized provider events produce a persisted batch. The full workspace suite still times out in two desktop localDevRebuild tests under parallel load; that file passes when run in isolation.