feat(scheduler): drive each pipeline from one server with MySQL named locks

[wellCh4n]

Every backend server runs every @Scheduled job. The pipeline scans were safe only because each transition is a conditional UPDATE, and the scheduled-restart and resource-alert scans were not safe at all: two servers fired the same restart and sent the same alert in the same minute.

NamedLockRegistry (infrastructure/lock) puts MySQL user-level locks (GET_LOCK / RELEASE_LOCK) on one dedicated connection per server, opened with DriverManager from the datasource properties and kept outside the Hikari pool for the life of the process. A lock lives exactly as long as its session, so a dead server's locks are freed the moment its connection drops — no lease to renew, no clock involved. The registry is fail-closed: with its connection down a server drives nothing until it reconnects, which is recoverable, whereas two servers driving the same thing is what the lock exists to prevent. It validates the idle session every 30s so wait_timeout never reaps it unnoticed.

The pipeline scans take one lock per pipeline (oops:pipeline:{id}), so one server drives a pipeline from build through rollout while other servers drive other pipelines. The rollout scan sweeps locks whose pipeline was finished elsewhere (a user stopping it from any server); it snapshots the held locks before it queries the active pipelines, so a lock the build scan takes concurrently is never swept as no longer active. The restart and alert scans take one sticky lock each on their first tick and keep it, so one server leads until it goes away — releasing after each tick would let a second server's tick in the same minute fire the same restart again.

The lock is not a fence. A server whose session MySQL cut keeps believing in its locks until it next talks to the registry, which is why every pipeline transition still goes through updateStatusIfMatch: the lock makes collisions rare, the CAS makes them harmless. That is the same split client-go's leader election documents for itself.

Reviewing the state machine for that turned up four gaps, fixed in the second commit. stopPipeline saved the whole row unconditionally, so a stop could overwrite a deploy the scan job had just claimed, which then ran to completion under a pipeline that said it was stopped; it now transitions from the status the caller read and fails with "state changed concurrently" when that read is stale. completeDeployPhase ignored the result of its DEPLOYING → ROLLING_OUT claim, so a pipeline stopped while its artifact was applied was announced as rolling out anyway. A RUNNING pipeline whose build Job the cluster no longer had (deleted by hand, work namespace cleaned, TTL-reaped) mapped to UNKNOWN and matched no branch, so it stayed RUNNING for good and the application could never be deployed again; a missing Job now fails the build at once, and a Job that exists without a status is still left for the next tick. Nothing looked at DEPLOYING, so a server dying mid-deploy left the pipeline there forever with the same effect; the rollout scan now fails a pipeline that has stayed DEPLOYING for ten minutes. That timeout is measured from when the scanning server first saw the pipeline deploying, because no column records status-change time and the conditional updates bypass entity timestamps — a restart only starts the clock again. If a precise timestamp is preferred, the alternative is a status_changed_time column written by the conditional updates.

Rebased onto main after #101, which carries the SSE and integration-suite fixes this branch had first needed (the async-dispatch rule, the route inventory, the stream tests and the socket reader); those commits are dropped here in favour of main's. No schema change. AGENTS.md documents the lock under "Multi-server coordination". The backend suite (300 tests) passes against a throwaway mysql:8.4.

[wellCh4n]

Integration result, tests/integration/run.sh --module streams against a local k3s at 8c86a73:

OK     1m55s  step watch reports every step of a finished build
OK      0.3s  step log replays a finished step and does not replay it on reconnect
OK     20.1s  pod log socket streams text lines
OK      0.1s  pod log socket answers ping with pong
OK      8.0s  terminal socket does not answer ping
DONE 2m24s  5 passed

The CI run on 98ff624 failed on exactly the things the three commits since then fix: the two SSE tests (the async-dispatch denial truncating every stream), the pod log ping test (socket closed for want of environment), and the /log route showing as uncovered only because the log test never got past steps/watch.

[wellCh4n]

Superseded by #102: the branch was rebased onto main after #101 (which carries the SSE and suite fixes this PR had first needed), and GitHub will not reopen a closed PR whose head was rewritten.