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.