Drop the Code update workflow

[ru-sh]

Code updates can come from coder/code-server, which runs this same scheduled job and refreshes the patch stack against each new release. Running our own copy means this fork owns that rebase instead of reviewing one upstream merge, so the workflow is removed.

It was also failing. The job ends in the same gh pr create that #4 removes from publish.yaml, with secrets.UPDATE_PR_TOKEN || github.token and no secrets set on this repository:

pull request create failed: GraphQL: GitHub Actions is not permitted to create or approve pull requests (createPullRequest)

It pushed update/1.138.0 on 2026-09-18 and could not open the PR. Every run since reports success while doing nothing: the check step treats the existence of update/$VERSION as proof a PR is already open, so it short-circuits.

That branch should not be merged, and it is worth saying why, because the failure is not in the PR step:

• patches/csp-hashes.diff is missing from patches/series, but the file itself is still there and byte-identical to main's (blob 422ca3b6)
• CHANGELOG.md is untouched, so add_changelog never ran either

update-vscode.sh deletes the CSP patch on purpose each run (delete_csp, "Hashes are always regenerated to avoid having to resolve conflicts") and update_csp is meant to recreate it with recomputed sha256 hashes. The delete landed; the regenerate did not, and the steps after it never ran. main() ends in run-steps "${steps[@]}" || true, so the script exited 0 anyway and git add . committed the half-finished tree.

So the broken gh pr create was the only reason anyone noticed. Had it worked, this would have opened as a routine-looking draft PR with the webview CSP hashes silently missing.

ci/build/update-vscode.sh is kept — with no VERSION it re-refreshes patches and regenerates CSP hashes, which is still what you want when an upstream merge leaves them conflicting. docs/CONTRIBUTING.md now says so, since the workflow was its only caller.

Follow-ups, not in this PR:

• origin/update/1.138.0 is stale and should be deleted.
• The swallowed failure in update-vscode.sh (|| true) is worth fixing if the script stays in manual use, since it will hide the same thing when run by hand.

🤖 Generated with Claude Code

---

Correction (added after merge). The diagnosis above is wrong about which step failed. The run log for 35404425408 shows:

Revert CSP hashes...
Update Code to 1.138.0...
Refresh Code patches...
  | Refreshed patch patches/proposed-api.diff
  | Failed
Update Node version...      | Skipped
Regenerate CSP hashes...    | Skipped
Add changelog note...       | Skipped

refresh_patches failed — a patch did not apply against 1.138.0 — and run-steps then skipped everything after it. update_csp never ran at all, so the CSP patch was not "deleted but not regenerated"; it was deleted by delete_csp and the regeneration step was skipped. One failure explains all three observations (CSP patch absent from the series, .node-version unchanged, CHANGELOG.md untouched).

run-steps ... || true is also not a defect. run-steps records each step in .cache/checklist as - [X] or - [ ], and the workflow passed that file as the PR body, so failures were meant to surface as unchecked boxes in the draft PR. The || true is there so the script can still append the final "Verify changelog" line after a failure instead of aborting under set -e.

The real defect is in refresh_patches: it calls quiet quilt push, and quiet() is "$@" >/dev/null. quilt prints Patch <name> does not apply on stdout, so the name of the patch that broke is discarded while only the exit code survives. That is why the log says Failed without saying what failed.