Handle SQLite WASM worker readiness so first queries don’t hit the 5s follower timeout #21

Current behaviour

• SQLiteWasmDatabase.new() returns immediately after spinning up a worker, but there’s no signal that the worker has finished acquiring the navigator.locks lock or opened the underlying SQLite database.
• Callers often issue queries straight away. If the worker is still in its “follower” state, WorkerState::execute_query queues the request on the broadcast channel and races it against schedule_timeout_promise(…, 5000 ms). When no leader exists yet, the race always rejects with "Query timeout" even though the database is still initializing.

Desired behaviour

• Provide an explicit readiness hook so callers can wait until the worker has a live connection before issuing SQL.
• If a query arrives before leadership is established, reject immediately with a clear initialization error (e.g. InitializationPending) instead of waiting for the timeout.
• Ideally make the follower timeout configurable rather than hard-coded.

Proposal

1. Extend the JS API (e.g. SQLiteWasmDatabase.ready(): Promise) that resolves after WorkerState::attempt_leadership succeeds and the worker posts its worker-ready control message.
2. Detect the “no leader yet” condition in execute_query and reject promptly with a dedicated error; only use the timeout when a leader fails to answer.
3. Surface the timeout duration through configuration so consumers can tune it if needed.
4. Document the new readiness/initialization flow so downstream users know to await readiness or retry on the explicit error.

This would eliminate spurious "Query timeout" errors during normal startup and make it easier for consumers to coordinate with the worker lifecycle.