Remove conn->db NULL guard from multi_step; fix stale NIF from prior run

The conn->db == NULL guard in exqlite_multi_step broke the
'exceeding timeout' integration test. sqlite3_close_v2 uses deferred
close: the sqlite3* stays valid (zombie state) until all prepared
statements are finalized, so multi_step can legitimately run after
a connection close while a query is in-flight. The guard was not
needed: conn->db cannot change during the loop because the connection
lock is held, and statement->statement NULL is sufficient protection
against use-after-release.

Author: mjc

c_src/sqlite3_nif.c

@@ -792,11 +792,6 @@ exqlite_multi_step(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[])
 
     connection_acquire_lock(conn);
 
-    if (conn->db == NULL) {
-        connection_release_lock(conn);
-        return make_error_tuple(env, am_connection_closed);
-    }
-
     if (statement->statement == NULL) {
         connection_release_lock(conn);
         return make_error_tuple(env, am_invalid_statement);

test/exqlite/sqlite3_test.exs

@@ -1026,10 +1026,9 @@ defmodule Exqlite.Sqlite3Test do
 
     # Targets statement use-after-release in exqlite_multi_step.
     # After Sqlite3.release(conn, stmt), statement->statement is NULL.
-    # The pre-lock check catches the sequential case, but there
-    # is a TOCTOU window between that check and the sqlite3_step() call
-    # inside the connection lock.  This test verifies the expected error
-    # return and documents the race condition.
+    # The pre-lock check catches the case where release happened before
+    # the call, and the inside-lock check catches the case where release
+    # races with the lock acquisition.
     test "multi_step after release does not segfault" do
       for _ <- 1..50 do
         {:ok, conn} = Sqlite3.open(":memory:")