Rust and Dart FFI Database Initialisation Refactor

A concurrency fix at the boundary between Dart and Rust. A cancelled foreign-function call was tearing down the future that owned an in-progress SQLite migration, leaving the database locked and the schema half-applied. The refactor decouples initialisation from the lifetime of any single caller, de-duplicates concurrent attempts, and keeps the public FFI interface unchanged.

Database initialisation ran inside the async task created by the Dart FFI call. If that call was cancelled — the caller times out, the screen is disposed, the app is backgrounded — the future was dropped, and with it whatever the migration was doing.

In async Rust, a dropped future simply stops at its last suspension point. There is no unwinding and no chance to finish. If the drop happens between two migration statements, the schema is left partly applied and the SQLite connection is torn down while it still holds a lock. The next call then finds a database that is both locked and in an inconsistent state — and because that call runs the same code, it fails the same way.

Cancellation in async Rust is not an error path — it is the absence of one. Dropping a future stops it at whatever .await it last reached, with no notification and no opportunity to clean up beyond what Drop implementations happen to do.

For most work that is harmless. For a migration it is not, because a migration is a sequence of statements that is only meaningful as a whole. Stopping between two of them leaves the schema in a state that no version of the code expects, and the connection holding the lock disappears without a clean close.

The worst property was that the failure was self-perpetuating. The retry ran the same cancellable path and inherited both the lock and the inconsistent schema, so a single badly-timed cancellation could keep the database unusable indefinitely.

The core change is that initialisation is no longer owned by the call that triggered it. A caller acquires a handle to a shared operation; the operation's own lifetime governs the migration. Cancelling a caller drops that caller's handle and nothing else — the migration runs to completion and releases its lock normally.

Moving the work to a blocking task serves the same goal from a different direction. SQLite migrations are synchronous, CPU- and I/O-bound work that has no business occupying an async executor thread, and a blocking task is not subject to the same drop-at-await semantics that made cancellation destructive in the first place.

Once initialisation outlives its caller, several callers can arrive while it is still running. Letting each start its own migration would reintroduce the lock contention the refactor exists to remove, so concurrent attempts are collapsed into one: the first caller starts the work, everyone else waits on the same result.

Failure has to be handled separately from success. A completed initialisation is cached and never repeated; a failed one must not be, or a single transient error would poison every future attempt. The shared state therefore distinguishes 'done' from 'attempted and failed', and only the former short-circuits.

The behaviour worth testing is the one that caused the bug: cancel a caller mid-initialisation and assert that the migration still completes, the lock is released, and a subsequent call succeeds. Alongside that, concurrent callers should produce exactly one migration run, and a forced failure should leave the system retryable rather than permanently broken.

Because the public FFI interface is unchanged, existing callers exercise the new implementation without modification — which is the most useful validation available, since the original failure only appeared under real timing.