Migrations run implicitly per pool-connection against the live DB

Severity: medium.

### Summary

`apply_migrations` runs in the pool's `create()` for each of up to 16 connections (`crates/node/src/database/sqlite/connection_manager.rs:100-106`, `migrations.rs:12-22`). The `add_seq_cursor` migration is a full table rebuild (create new table, copy all rows, drop old).

### Impact

- No operator-controlled migration step: merely starting a new binary against a production file rewrites the whole table, with startup stalls proportional to DB size and no backup taken first.
- Concurrent lazy connection creation can race (`pending_migrations` is computed before the write lock), so a second connection may attempt an already-applied migration and fail connection creation.
- `migrations.rs:13` `.expect("In memory migrations never fail")` panics on any I/O error from `pending_migrations` (which reads `__diesel_schema_migrations`); deadpool catches the panic and fails the connection, but it's still a latent panic path.

### Recommendation

Run migrations exactly once at startup on a dedicated connection before building the pool; keep per-connection setup to PRAGMAs only; replace the `expect` with error propagation. Consider a `--migrate` gate and a startup log of applied versions.

---
Part of #114.

Examine the connection manager in crates/node/src/database/sqlite/connection_manager.rs and the migration logic in migrations.rs. The issue is about moving migrations out of the pool creation and ensuring they run once at startup. Start by understanding the current flow of apply_migrations and how pending_migrations is computed. A successful fix will involve creating a dedicated migration connection, handling errors properly, and adding logging.

Vom Indexierungsmodell aus dem Issue-Text verfasst.