server_*_tool_calls records are unbounded — the other ~432MB of the 940MB config.db in #1173 #1176

Summary

#1173 / #1174 caps the Response text on activity records. It does not touch the other activity-adjacent store, which on the reporting deployment held roughly 432MB of a 940MB config.db — more than the records that PR fixes.

storage.Manager.RecordToolCall (internal/storage/manager.go:1040) writes into per-server server_<id>_tool_calls buckets, and ToolCallRecord.Response is a bare interface{} (internal/storage/server_identity.go:66) with:

• no per-record size cap,
• no total-size cap for the bucket,
• no age-based prune.

So one large upstream response is persisted whole, per server, forever.

Why file it separately

#1174 deliberately scoped itself to the activity write path and the cap that was declared-but-never-read. Widening it to a second store with a different record type, different buckets and no retention machinery at all would have made an already-large review unreviewable. But #1173 should not close until this is fixed, or the reporter fixes half their database and comes back.

Also in scope

• ErrorMessage, Arguments and Metadata remain unbounded on activity records (internal/httpapi/activity.go says so in its own comment). A 10MB upstream error still lands whole. The new response cap creates a false impression that records are bounded.
• BBolt does not return freed pages to the OS. Even once caps and retention prune the old records, an existing 940MB config.db stays 940MB on disk. There is no compaction path today. Users need either a mcpproxy doctor-driven compaction step or a documented bbolt compact / export-reimport procedure, and the fix(activity): apply activity_max_response_size on the write path #1174 release notes should point at it.

Suggested direction

Reuse the shape #1174 established rather than inventing a second one: a configured per-record cap, applied on the write path, with a distinct truncation flag so consumers can tell a shortened record from a whole one. Then decide whether server_*_tool_calls needs its own retention policy or should fold into the activity log's.