fix: read refs inside setTimeout to prevent stale closure in debounced save

[hobostay]

Summary

• Fix stale closure bug in handleContentChange where the debounced save writes content to the wrong file
• projectId and filePath were captured from refs at scheduling time; if the user switches files during the 600ms debounce window, the save writes to the previous file

Details

Affected file: packages/studio/src/App.tsx (lines 631-651)

The setTimeout closure captured pid and path from the outer scope at the time the timeout was scheduled. If the user edits file A, then switches to file B within 600ms, the debounced save would write file B's content to file A's path.

The fix moves the ref reads inside the setTimeout callback so they always reflect the current state at execution time.

Test plan

• Edit file A, quickly switch to file B (< 600ms), verify file A is unchanged and file B has the new content
• Verify normal editing and saving still works

🤖 Generated with Claude Code

[jrusso1020]

Verified the stale-closure bug at App.tsx:639–650: pid and path are captured at scheduling time, so a file switch inside the 600ms debounce window writes content into the previous file. Reading from projectIdRef/editingPathRef inside the timeout fires fixes it; the early-return guard for missing values is also a correct safety net. LGTM.