dbfile: fix use-after-free and leak when recreating a rejected hashfile

[martinus]

What this fixes

When an existing hashfile fails dbfile_check() (a schema-version or hash-type mismatch — e.g. opening an older hashfile with a newer duperemove), dbfile_prepare() takes the "Recreating hashfile" path: it sqlite3_close()s the handle, unlinks the file, reopens a fresh one, and recurses.

But the handle was passed by value, so the reopened handle only ever lived in dbfile_prepare()'s local variable. Its caller, __dbfile_open_handle(), kept — and returned — a pointer to the closed handle.

What happens without the fix

__dbfile_open_handle()'s caller then runs sqlite3_prepare_v2() on that freed handle — a use-after-free (SQLITE_MISUSE / "Database error 21") — and later sqlite3_close()s it a second time, while the real working handle opened during recreation is leaked (~160 KB, "definitely lost" under valgrind). Normal runs happen to read the freed-but-intact memory and pass, so it's a latent defect; valgrind surfaces it reliably whenever a hashfile is rebuilt.

The fix

Pass the handle by reference (sqlite3 **) so the freshly-opened handle propagates back to the caller, and bail out cleanly if the reopen fails (the previous code would also have recursed into dbfile_prepare(NULL)).

Found via valgrind in the oans fork, whose strict hashfile branding makes the recreate path easy to hit — but the defect is inherited straight from here.