create-pr: synthetic commit approach could leave stranded commit on process crash

[jamesadevine]

Problem

The generate_patch() function in src/mcp.rs creates a synthetic commit (git add -A + git commit), runs git format-patch, then resets it (git reset HEAD~1). If the process is killed (OOM, SIGKILL) between commit and reset, the synthetic commit persists in the agent's working directory (not a worktree), potentially confusing subsequent agent invocations.

Suggested Fix

Consider a lighter alternative that avoids committing:

• Use git stash --include-untracked before the merge-base diff, then git stash pop
• Or pass --cached + unstaged diffs separately to avoid modifying git history

Context

The current implementation handles soft errors correctly (the reset runs before propagating format-patch errors, and the SHA is included in error messages). This issue is specifically about hard process kills that bypass cleanup. Low probability but worth a FIXME note if the synthetic-commit approach stays.

Identified in PR #155 review.

[jamesadevine]

After investigation: the agent runs inside an ephemeral AWF container. If the process is hard-killed (OOM, SIGKILL), the container and its entire filesystem are destroyed when the pipeline completes. The next pipeline run gets a fresh checkout — there is no "next invocation" in the same directory where a stranded commit could be detected.

The synthetic commit pattern is safe in production because the execution environment is disposable. A stash-based alternative was considered but git stash does not support format-patch rename detection and binary handling.

Recommend closing as won't-fix — the risk only exists in local development outside the pipeline, which is not a supported execution path.