fix(debug): bound unbounded SDK message log writes

[fristovic]

Problem

Agent sessions can write unbounded SDK payloads into debug.log (e.g. large tool_result content), so a single run can grow the log without a ceiling and make debugging slow or disk-heavy.

Closes #578

Changes

• Sanitize SDK messages before logging: compact JSON, truncate large string leaves, avoid mutating the live message
• Cap each logToFile write at 8KB
• Stop appending once the log file reaches 10MB
• Keep short API/error payloads readable; signal extraction still runs on the raw SDK message

Test plan

• pnpm exec vitest run src/lib/agent/__tests__/sdk-message-log.test.ts src/utils/__tests__/debug.test.ts
• Manual check: 100KB tool_result formats to ~2KB; original object unchanged
• End-to-end write check: SDK-style logToFile stays under the 8KB line cap; further writes stop at the 10MB file ceiling

LLM context

Co-authored with Cursor. Implemented and verified locally (unit tests + manual size-cap checks) against #578.

[gewenyu99]

Thanks for taking this up!

Great heuristic, it definitely needs to be bounded, but I think the solution isn't super useful here.

I don't think truncating model responses is useful. That is one of the primary ways we debug and analyze what the model is trying to do. Maybe truncating it only on prod builds, but even then, when we ask for logs on support tickets, this becomes a pretty hard blocker.

The behavior to have logFileCapReached permanently disable logging is also not super helpful. Maybe we can rotate logs, maybe it should be new file per run, delete the oldest run when a new run starts past a set N number of files?

What do you think?

[fristovic]

@gewenyu99 🤦 ...now it makes total sense.
I actually went down the truncation path because that was listed under Fix direction in #578.

Yes I totally agree here. I would follow your suggestion: one artifact per run, keep the last N runs, delete the oldest when past N, and never stop writing mid-run. Would you say setting N to 5 as a named constant that is easy to change if that is the wrong number would be the right approach here?

I am much less sure about what dominates size inside a single run 🤔 I have not measured a real wizard log yet. Could you share a sample log for reference? I am especially interested in tool_result payloads from things like Read/Bash/Grep, as #578 suggested.
With that, we can compare the main cost versus assistant text and I think that will indicate clearly if they belong in the primary log, a sidecar, or behind a flag, without touching model responses. That said, I would not necessarily push that into this PR if it means a bigger refactor of the whole mechanism, if you agree?

Also, one more thing - Looking back at #578, the lowest-risk first step there was dropping pretty-printing (JSON.stringify(message) instead of null, 2). Happy to include that as a small hygiene change if you want.