Guard all four PyCoder result/error handlers against a disposed node

[dovvnloading]

Summary

PyCoderNode's result/error handlers were the one worker-result-handler family with no is_disposed guard at all — every sibling (_handle_artifact_result/_handle_artifact_error, _handle_code_sandbox_result/_handle_code_sandbox_error) already had one.

Manual-mode execution finishing kicks off a second, window-level thread (self.pycoder_agent_thread, a PyCoderAgentWorker with no stop() of its own — an in-flight LLM call can't be cancelled early) to get an AI analysis of the output. If the node is deleted mid-execution or mid-analysis, dispose() has no way to reach or stop this second-stage thread — it only knows about the node's own worker_thread, not the window's separate pycoder_agent_thread attribute. When the analysis result (or an error) later arrives, the handler used to mutate, reselect, and save-chat a node no longer on the canvas. The AI-driven mode's single-stage result handler had the identical gap — it wasn't specific to the two-stage manual-mode flow.

Changes

All four handlers now guard on is_disposed, matching the established sibling pattern exactly:

• _handle_code_execution_result — additionally stops a pointless second-stage analysis thread from ever starting for a node that's already gone
• _handle_pycoder_analysis_result
• _handle_ai_pycoder_result
• _handle_pycoder_error (shared by all three PyCoder worker stages)

Test plan

• New regression tests for all four handlers (disposed-node and None cases)
• End-to-end test: delete the node mid-manual-execution, confirm the late finished signal touches nothing and never starts stage 2
• Full suite: 1703 passed, zero regressions

Fourth of the fixes from the recent adversarial bug-scan (after #91, #92, #93).