Implementation Plan: Register SeedSampleChallenges migration in DatabaseModule

1. Architectural Reconnaissance

Codebase style & conventions: NestJS + TypeORM; migrations are registered manually via an in-source MIGRATIONS array (not a filesystem glob) in backend/src/database/database.module.ts. Imports follow chronological order matching the array.
Data Layer: SQLite via better-sqlite3. DatabaseInitService.init() (called from main.ts before app.listen()) executes dataSource.runMigrations({ transaction: 'each' }), which uses the MIGRATIONS array registered with TypeOrmModule.forRootAsync. Until the array contains the new class, npm run setup and the first app boot will not run SeedSampleChallenges1700000000600.
Test framework: Jest; backend tests construct their own in-memory DataSource with an explicit migrations: [...] list — they bypass DatabaseModule, which is why migrations.spec.ts (already updated for Job 906) passes despite this gap.
Required tools & dependencies: none.

To Modify:
- backend/src/database/database.module.ts — add the import and append the new migration class to the MIGRATIONS array, right after UpgradeChallengeAdminSchema1700000000500.

Edit database.module.ts:
- Add the import alongside the other chronological migration imports (between .../1700000000500-UpgradeChallengeAdminSchema and the next non-migration import DatabaseInitService):
```
import { SeedSampleChallenges1700000000600 } from './migrations/1700000000600-SeedSampleChallenges';
```
- Append to the MIGRATIONS array, immediately after UpgradeChallengeAdminSchema1700000000500:
```
SeedSampleChallenges1700000000600,
```
No other code changes. The migration class already exists, is exported, and is covered by tests in tests/backend/migrations.spec.ts. Once registered in the TypeORM MIGRATIONS array, DatabaseInitService.init() (called via main.ts and indirectly by npm run setup) will execute it on next boot.
Verification expectation: After npm run setup (or first boot on a fresh DB), SELECT COUNT(*) FROM challenge; returns > 0 and the eight sample names are present. Re-running setup on a DB that already has rows is a no-op (the migration's early-return guard).

No new automated tests required. The existing tests/backend/migrations.spec.ts already asserts the seed runs and that values are schema-compatible, schema-correct, and down() is scoped correctly. The fix is purely a wiring change that registers an already-tested class with the production DatabaseModule, which has no dedicated test (and per the Jobs rule, no new test files should be introduced for a 2-line wiring fix).
Manual smoke (tester steps, no UI): on a fresh DB file, run npm run setup then sqlite3 ./data/db.sqlite 'SELECT COUNT(*) FROM challenge;' and confirm the count is 8; on a re-run, confirm the count is unchanged (idempotent guard works).