Service fails to restart after the first successful deploy

Every chronos replica applies migrations on startup before serving traffic. If Migrate() crashes on any restart after the very first one, the service can never come back up -- not after a routine redeploy, not after a crash, not after a node reschedule in Kubernetes. This is a cannot-start-at-all bug: the first deploy works, and every deploy after that is an outage. On-call would see every replica crash-looping against a healthy database, a uniquely confusing failure mode at 3am because the database is fine and the migrations are fine -- the code just refuses to believe it.

db.Migrate (in internal/db/db.go) calls golang-migrate's m.Up() and treats any non-nil error as fatal: if err := m.Up(); err != nil { return fmt.Errorf("apply migrations: %w", err) }. m.Up() returns migrate.ErrNoChange when the schema is already at the latest version -- the expected, successful outcome on every restart after the first. Treating it as fatal means the second, third, and every subsequent startup errors out immediately.

1. Point DATABASE_URL at a fresh Postgres database.
2. Call db.Migrate(url) -- succeeds, schema created.
3. Call db.Migrate(url) again against the same database (exactly what happens on a second go run ./cmd/chronos, or a second container start in the Docker stack).
4. Observe: the second call returns an error, "apply migrations: no change".

golang-migrate uses ErrNoChange as a sentinel for "already up to date" rather than a special return value, precisely so callers can distinguish it from a real failure with errors.Is. Skipping that check conflates "nothing to do" with "something went wrong."

Look at how Migrate() currently decides whether m.Up()'s error is fatal. There is a well-known sentinel error (migrate.ErrNoChange) exported by the github.com/golang-migrate/migrate/v4 package specifically for this situation, and the standard library's errors package has a function for checking whether an error is (or wraps) a specific sentinel.