A timed-out session's uncommitted work is discarded with the worktree

[lorenzoliuzzo]

Measured on the same real run as #18. The transcript shows the session made its edits to model.py and tests/test_model.py within its first few turns, then spent the remaining ~20 minutes trying to get the target repo's dependencies installed so it could run the suite. It was killed before it ever ran git commit.

_attempt measures durable work as _commit_count(tree, base_sha). Uncommitted edits are invisible to it, so the outcome was failure with files_touched: [], and the worktree — with the finished edits still in it — was destroyed on the way out.

This is the same class of loss v0.3's checkpoint branch was built to prevent, but that mechanism only rescues commits. The prompt makes it worse by ordering the work the natural way — "make the change, run the suite, then commit" — so a session that is slow anywhere before the last step banks nothing at all.

Acceptance criteria

• A session killed by the wall clock does not lose edits that were already made: either my-coder commits the dirty worktree itself as a checkpoint before tearing it down, or the outcome carries the diff.
• The prompt tells the session to commit incrementally rather than only once at the end, so partial progress survives independently of my-coder salvaging it.
• The salvaged state is distinguishable from work the session chose to commit (a needs_review checkpoint, not a success).
• A test covering a timeout with a dirty, uncommitted worktree.