Map code action edits back to the notebook

[thomasjm]

A code action's edit came back untouched: the shadow file's uri, the shadow file's version, and lines in the generated wrapper's coordinates, so a client that applies edits by document name refuses it. Same bug as codedownio/rust-notebook-language-server#3, same fix.

transformServerRsp' for textDocument/codeAction filtered the list through an isInternalReferringCodeAction that always returned False, and nothing rewrote the edit. There was no codeAction/resolve case, so it fell through untouched too.

Now untransformWorkspaceEdit rewrites documentChanges and changes: shadow uri to the notebook's, version to null, every range back through the transformer. An action is dropped when it can't be expressed against the notebook — it names another document, it creates/renames/deletes a file, or one of its edits lands on a line the projection introduced. Half-applying an edit would corrupt the cell.

codeAction/resolve carries no document, so the transformer is found from the shadow uri inside the edit (lookupTransformerByNewUri). If that fails the edit is dropped rather than returned wrong.

Bare Commands pass through: their arguments are opaque, so there's nothing to rewrite and no safe way to tell whether they refer to the shadow file.

---

Parked. This is the same fix written four times, which is the duplication the shared-core work is meant to remove. Holding it until the Transformer class is reconciled across the four proxies, then reapplying it once. Branch kept; see plans/consolidating-the-notebook-proxies.md in haskell-notebook-language-server.

---

Closed, to be redone at the end. This predates the Transformer/ProjectIn reconciliation, so it needs rewriting against the new class rather than rebasing — getParams is gone and unproject no longer takes Params. Branch code-action-edits is kept. The matching integration test is on codedown-languages branch rust-code-action-test.