Run.hasChanges and Robot.compareRuns have no migration, so every run fails after an upgrade

On any database created before d0014e0, every run fails in under a second:

Error scheduling run: column "hasChanges" of relation "run" does not exist
2026-09-11 error: Error running robot: runId or userId is undefined
2026-09-11 error: [SDK] Error executing robot: Failed to start robot execution

and the queue worker then retries against the same missing column:

error: Error processing queued runs (1/3): column "hasChanges" does not exist

Cause

d0014e0 ("Add compareRuns to Robot model and hasChanges to Run model, add diff dependency") added two model columns and no migration:

server/src/models/Robot.ts | 1 +
server/src/models/Run.ts   | 7 +++++++
package.json               | 2 ++

The latest migration in server/src/db/migrations is 20260707173443-add-run-is-partial.js, and neither hasChanges nor compareRuns appears in any migration.

A fresh database is fine, because sequelize.sync() creates the columns from the models. An existing database never gets them, so upgrading breaks every run.

Reproducing

1. Start a release that predates d0014e0 (I used getmaxun/maxun-backend:v0.0.61) and let it create the database.
2. Stop it and start a backend built from current develop against that same database.
3. Trigger any run.

Every run fails immediately. Against a fresh database on the same backend build, the error does not occur — which is the part that isolates it to the missing migration rather than to the run path.

Suggested fix

A migration adding both columns with the defaults the models declare — Run.hasChanges and Robot.compareRuns.

I have not written it, because the right defaults and backfill for existing rows are a product decision rather than a mechanical one: whether pre-existing runs should read as "no changes" or as unknown is your call, and getting it wrong silently mislabels historical runs.

Happy to send a PR if you tell me which you want.

Noted while tracking down a separate bug (#1211). Worth flagging that this one masks that one: the run dies before a socket is opened, so anyone reproducing the API/SDK/scheduled-run hang on an upgraded database sees this fast failure instead.

Written with AI assistance; reproduced and isolated as described above.