feat: per-frame tracing buffer that dumps on panic

[tonybierman]

Replaces the always-on debug-mode file log with a per-frame in-memory buffer that captures tracing events emitted during run_rewrite_passes and dumps them to a $TMPDIR/masonry-*-panic.log file only when the process panics. Closes #1556.

[xStrom]

Hi Tony, thanks for the PR. Would you be so kind to describe a bit of the process you went through when making these changes? I'm just wondering if this is a result of Claude's thinking or if you played any role in it too. Basically, what differentiates it from a simple Claude prompt? Just so I know how to approach reviewing it.

[tonybierman]

Phase 1
I point claude to the issue #, ask it define a statement of work in the form of a concept statement and check list of tasks. It analyzes the code base and comes back to me with a series of tasks to meet the work requirements. I try to tackle small issues with well-defined boundaries. Particularly if I'm not familiar with the code base yet. We go through the task list until we have a first blush. I do a walk through of the code (in vscode). After that we iterate a process that looks something like this:

Stage 2

• Did we create any magic numbers or assumptions?
• work order, human review
• Did we create multiple versions of the truth or commit DRY violations?
• work order, human review
• Are all functions, variables and constants named idiomatically?
• work order, human review
• Are all functions, variables and constants scoped correctly?
• work order, human review
• Are there any stale, unnecessary, turgid, or inaccurate comments?
• work order, human review
• Is the uncommitted code well-structured?
• work order, human review

Stage 3
I ask claude to look for code smells. we usually do that about three times. Maybe 4 or 5 if I don't like what I see. Same process as before - checklist, walk-through, repeat.

Stage 4

• Are the uncommitted code and comments in compliance with the repo's standards and practices?
• work order, human review
• Does the repo have any guidance on submitting PRs?
• work order, human review

Stage 5
Submit PR

Background
I'm a retired developer, project manager, and exec. This is roughly the same process I've used with human developers for about two decades. My background is mostly in C#. I've been working with Rust for about a year.

I'd add that I like xilem/masonry project. I've been reading the docs and playing with it. I like the philosophy behind it, and I think it has been designed very well. I wanted to contribute. I hope the PR meets your standards, which I find to be high. If you want me to fix something, tell me about. If you want me to close the PR, no problem. No hard feelings.

My opinions about agent assisted coding. You have to put bumpers on the agent. You have to iterate, refactor, walk-through. If you follow a tight regime, you can produce a pretty good product. If you feel otherwise about the result, or the process, I know you're busy, but let me know.