fix: release the update lock when the update launcher rejects (#6036)

[atomantic]

Summary

POST /api/update/execute acquires the atomic update lock, then fires executeUpdate without awaiting it. Both of executeUpdate's resolved outcomes clear the lock through recordUpdateResult, but a rejection — e.g. spawnDetached throwing on a permissions or missing-binary failure, before any child listener is attached — skipped that path entirely. The route's .catch emitted portos:update:error and left updateInProgress set.

That stuck lock wedged the whole install: every later update answered 409 UPDATE_IN_PROGRESS, and isUpdateInProgress() blocked every CoS agent spawn, until the 30-minute stale timeout aged it out or the server was restarted.

• server/routes/update.js — the .catch now releases the lock. The rejection is not swallowed: it is logged and still reaches the socket error channel first (the HTTP response is long since sent), and a failure of the release itself is logged rather than left as an unhandled rejection.
• server/routes/update.test.js — backfills the execute route's untested branches. makeApp() never attached an io, so every socket emission the route makes was a silent no-op that no test could observe.

New coverage, each naming a distinct regression:

Test	Catches
executeUpdate rejects → lock released + portos:update:error	the bug above
409 UPDATE_IN_PROGRESS when the lock is held	ignoring the atomic check-and-set's false, allowing two concurrent update.sh runs
400 INVALID_TAG for a non-semver tag, lock untouched	removal of the option/argument-injection guard on the tag handed to update.sh
portos:update:complete with the resolved version	the client's only channel for the outcome
versionKnown: false fallback to the triggering tag	a guessed version being presented as confirmed
portos:update:error with the real failedStep	the resolved-failure path collapsing to 'unknown'
portos:update:step forwarding	the progress callback wiring that drives the update progress bar

One non-obvious detail worth flagging for review: attaching io also routes every error response through errorEvents, and a Node EventEmitter throws its payload when 'error' is emitted with no listener — which broke the error envelope for every non-200 case in the file. The real server always has a subscriber, so the suite registers a no-op stand-in.

Test plan

• Verified the regression test fails on the unpatched route (1 failed | 40 passed) and passes with the fix.
• cd server && npx vitest run routes/update.test.js → 41 passed.
• Full server suite (also globs ../scripts, ../lib, ../autofixer) → 1917 files passed, 38680 tests passed, 0 failed.
• Local code reviewer: no findings.
• No DB-backed suites run.

Closes #6036

https://claude.ai/code/session_01VjkWVTfzKyRuAv3HEsspwN