verify-migration.sh: treat lagging target sequences as a failure, not a warning

In verify-migration.sh, section 9 (SEQUENCES) compares last_value for each sequence between source and target. When a target sequence is behind the source, it only emits log_warn and increments SEQ_BEHIND — but SEQ_BEHIND is never wired into the script's exit code (it only gates the log_pass line, ~verify-migration.sh:566-579).

Impact: an operator running verification before cutover sees a yellow warning, not a failure. If target sequences lag the source (e.g. they were never reset after CDC), the target will hand out already-used IDs after cutover — duplicate-key errors on first writes. Verification should stop this, but currently doesn't.

Proposed change: make a lagging sequence (SEQ_BEHIND > 0) a hard failure with a non-zero exit, consistent with the other blocking checks in the script.

Context / why now: the underlying pgcopydb gap — sequences not being reset after a resumed CDC follow — is fixed in planetscale/pgcopydb (sequence reset on pgcopydb follow reaching endpos). This issue is defense-in-depth: even with that fix, verification should fail loudly if sequences are ever stale, so a future regression can't slip through to cutover.

Start in verify-migration.sh, section 9 (SEQUENCES), especially the logic around lines 566-579, and trace how blocking checks contribute to the script exit status. Verify the behavior with a target sequence behind the source: it should emit a failure and return non-zero instead of only warning. Confirm that non-lagging sequences retain their current passing behavior.