Narrow ownSaveInFlight edge case: same-client YJS_UPDATE failure right after a save can clear it prematurely #1483

Background

PR #1480 (Collaborative script editing: Phase 3, Step 4 — Save/Stop/Discard + bulk edit, client-v3) fixed a leak in scriptDraft.ts's ownSaveInFlight flag: a save rejected via COLLAB_ERROR (not just SAVE_ERROR) wasn't clearing it, leaving isDraftSaving/isDraftDirty stuck. The round-2 fix made collabError() also clear ownSaveInFlight when it's set.

Round 3 of the review flagged a narrower residual edge case in that same fix: if a same-client YJS_UPDATE fails to apply immediately after a save is sent (before the real SAVE_ERROR/COLLAB_ERROR response for that save arrives), the update-failure path could end up clearing ownSaveInFlight prematurely too — since collabError() doesn't currently distinguish "this COLLAB_ERROR is the rejection for the save I just sent" from "this COLLAB_ERROR is for something else entirely that happened to arrive while a save was in flight."

The reviewer explicitly called this optional/non-blocking: "worth a follow-up issue if you want to track it, but not blocking."

Proper fix

Needs a server-side change: have _op_save_script_draft's own rejection paths (live session became active, or _require_editor_write_access failing) respond with a dedicated SAVE_ERROR instead of the generic COLLAB_ERROR, so the client can unambiguously tell "my save was rejected" apart from "some other collab error occurred while my save happened to be in flight." This is bigger than Step 4's PR scope (touches the save-rejection contract, not just this feature's own code), hence tracking separately.

Scope of this follow-up

• Backend: server/controllers/ws_controller.py's _op_save_script_draft — tag its own rejection paths with SAVE_ERROR instead of COLLAB_ERROR.
• Frontend: client-v3/src/stores/scriptDraft.ts — collabError() no longer needs to guess; saveError() remains the sole clearer of ownSaveInFlight.
• Add a regression test reproducing the same-client YJS_UPDATE-failure-during-save interleaving to confirm the fix.

Not blocking — current behaviour is correct outside this narrow interleaving window, per round 3's review.

Related: #889, #1480