cli: pick next -seq version by numeric max, not lexical last

[shaikn6]

What

Make migrate create -seq derive the next version from the numerically highest
existing migration instead of the lexically last filename.

Why / evidence

nextSeqVersion (internal/cli/commands.go) read the sequence prefix from
matches[len(matches)-1]. filepath.Glob returns paths in lexical order, so
once a project has both single- and multi-digit versions the last entry is
9_* (it sorts after 10_*, 11_*, ...). The next version was then computed
as 9 + 1 = 10, colliding with the existing 10_* files.

Reproduced with the scenario from #1109: a migrations dir containing 0_ .. 11_
pairs, then migrate create -dir ./migrations -seq -digits 2 -ext sql foobar
=> error: duplicate migration version: 10.

Change

In nextSeqVersion, iterate over every glob match, parse each numeric prefix,
and keep the maximum; next version is max + 1. Per-file malformed-name and
ParseUint errors are unchanged, so behaviour for well-formed input is
identical. One function, ~9 lines.

Verified

• Added table case Multi digit lexical order
  ([]string{"0_x","10_x","11_x","1_x","2_x","9_x"} -> 000012). Fails on the
  current code (got 000010), passes with the fix.
• go test ./internal/cli/ -> ok
• gofmt -l internal/cli/ clean; go vet ./internal/cli/ clean.

Fixes #1109

[coveralls]

coverage: 54.955%. first build — shaikn6:fix/nextseq-numeric-max into golang-migrate:master

[shaikn6]

Hi maintainers, the only failing check on this PR is the Go 1.25.x test job. The failures are Docker containers timing out on startup (sqlserver and yugabytedb: "timed out waiting for container to get ready"). Go 1.26.x, lint and coverage all pass. This change doesn't touch those drivers. Could someone with write access re-run the failed job? Thanks!