chore(migrations): renumber 108_add_backup_paths to 109 to avoid upstream collision

upstream/beta independently shipped 108_seed_sl_email_template_translations.js
(Slovenian email template translations) using the migration number
this branch had already claimed for 108_add_backup_paths.js. Knex's
filename-based ordering would have caused both to attempt the slot
at merge time.

Renamed via `git mv` so file history is preserved. All five
references updated in lockstep:
  - backend/src/services/_backupPathsBoot.js (require + comments)
  - backend/src/services/backupService.js (LEGACY_BACKUP_PATHS comment)
  - 3 integration test files (require + "migration 108" prose)
  - migration's own header comment, with a paragraph explaining the
    rename so reviewers don't wonder why the number jumped

**No data-migration impact for installs that already ran the
108-named version** (Ralf's beta, primarily): the migration's body
is idempotent — createTable is guarded by `hasTable`, and the seed
uses `onConflict('path').ignore()`. So when 109 runs against an
install whose backup_paths table is already populated, both the
schema step and the seed step no-op cleanly. The orphaned
`108_add_backup_paths.js` row in the `migrations` tracking table
sits harmlessly alongside the new `109_add_backup_paths.js` row.

No data lost, no double-insert, no schema drift. Mechanical rename
ahead of the PR opening.

backend/__tests__/integration/adminBackupCoverage.test.js

@@ -72,7 +72,7 @@ describe('GET /api/admin/system-health/backup-coverage', () => {
 
   async function restoreDefaultPaths() {
     await db('backup_paths').del();
-    const { DEFAULT_PATHS } = require('../../migrations/core/108_add_backup_paths');
+    const { DEFAULT_PATHS } = require('../../migrations/core/109_add_backup_paths');
     await db('backup_paths').insert(DEFAULT_PATHS.map((row) => ({
       ...row,
       created_at: new Date(),