release/v3.8.50: migration version collision at 135 and 136 (check:migration-numbering red)

[HouMinXi]

check:migration-numbering is red on the current tip (3c6f71776): two
version slots each have two physical files.

[check-migration-numbering] 2 anomalia(s) de numeração:
  ✗ prefixo de versão duplicado 135: [135_auto_restart_adopted.sql, 135_migrate_model_capability_max_token.sql]
  ✗ prefixo de versão duplicado 136: [136_dario_fallback_backend.sql, 136_radar_cache_settings.sql]

Both files at each slot are real, distinct migrations — this isn't the
allowlisted rename-compat case in KNOWN_DUPLICATE_VERSIONS (that set is
currently empty; nothing there covers 135 or 136).

Landing order, from git log -1 --date=iso-strict on each file (normalized to UTC):

Slot	File	PR	Landed (UTC)
135	135_migrate_model_capability_max_token.sql	#8908	01:41:38
136	136_radar_cache_settings.sql	#9515	08:58:58
135	135_auto_restart_adopted.sql	#8523	09:05:46
136	136_dario_fallback_backend.sql	#8523	09:05:46 (same commit)

#8523 landed after both #8908 (135) and #9515 (136) had already claimed those
slots, and merged without renumbering against either. Both of #8523's files
are the ones that should move — house convention here is "whichever lands
second takes the next free number," and 137/138 are both currently open.

Renumbering isn't a pure rename, though: check-migration-numbering.mjs's own
error text points at isSchemaAlreadyApplied in migrationRunner.ts for a
retroactive guard, since a DB that already ran migration 135 under the old
number needs the runner to still recognize it after the file moves. #8523 is
only hours old, so the compatibility window is probably small, but the guard
is the documented mechanism, not just the file move.

Impact beyond the gate itself: any test that reaches getDbInstance() with a
real (non-mocked) migration run hits this, e.g.

error: 'Migration version collision detected: version=135 → [auto_restart_adopted, migrate_model_capability_max_token]; version=136 → [dario_fallback_backend, radar_cache_settings]. ...'
  at getMigrationFiles (src/lib/db/migrationRunner.ts:263:11)
  at runMigrations (src/lib/db/migrationRunner.ts:827:53)
  at getDbInstance (src/lib/db/core.ts:1206:3)

Reproduced against upstream/release/v3.8.50 directly (blob hashes below are
identical to the local tree, so this isn't a fork artifact):

135_auto_restart_adopted.sql               11f805e7e315124a761d7b8f9e772c38cdc4ee1e
135_migrate_model_capability_max_token.sql be8fbecfda927947e81d49e9082113df1cf692c4
136_dario_fallback_backend.sql             28315188d3f03607efc256cdb5aa3f9f40b85b01
136_radar_cache_settings.sql               42bcec9d5eaee10fff4905c7a015bbb8af8f9a7e

Happy to open the renumbering PR if useful — flagging first since it touches
DB migration compatibility and I'd rather have the retroactive-guard shape
confirmed before writing it.