Bug

When script_apply_edits triggers a domain reload, the server's retry logic re-sends the edit command on each reconnect attempt. Since insert operations are non-idempotent, this causes massive duplication — in testing, a single insert_method call produced ~40 duplicate copies of the method.

Reproduction

1. Call script_apply_edits with an insert_method op on a MonoBehaviour
2. The edit succeeds and triggers a domain reload
3. Unity returns "Unity is reloading; please retry"
4. The server's recovered_from_disconnect retry path re-sends the same edit
5. Each retry appends another copy of the method

Expected

The server should either:

• Track that the edit was already applied (e.g. via SHA comparison) and skip retries
• Not retry write operations on "reloading" responses (the edit already landed on disk)
• Return success if the file was modified, even if Unity hasn't finished reloading

Observed

A single insert_method call produced 40+ duplicate TakeDamage methods in the file (grew from 23 lines to 300+ lines).

Context

Found during smoke testing of PR #787 (stdio bridge reconnection fix). The reconnection itself works correctly — the bug is that the retry logic doesn't distinguish between "edit failed" and "edit succeeded but Unity is still reloading."

Environment

• MCP for Unity 9.4.7-beta.9
• Unity 2021.3.45f2
• Transport: stdio