Apply query timeout while waiting for execution lock

[penberg]

The execution_lock introduced in #218 serializes operations on a
connection, but the query timeout was registered only after the lock
was acquired. Operations that piled up behind a busy connection could
wait many seconds in the queue while the configured timeout (e.g.
500ms) never fired, because the deadline only covered actual execution
time.

Fix: bound the lock wait by the query timeout via tokio::time::timeout
and register the time remaining against the absolute deadline with
QueryTimeoutManager once the lock is acquired. If the deadline
elapses while waiting, surface SQLITE_INTERRUPT — the same error a
user sees when a timeout fires during execution.

For prepare()'s stale-interrupt retry, the timeout guard is now
dropped before clear_stale_interrupt() and a fresh guard is registered
for the retry. If the deadline has already passed at re-register time,
register_remaining_timeout() returns SQLITE_INTERRUPT, so a stale
interrupt can no longer silently swallow our own timeout.

A reproducer is included at perf/query-timeout.js: with the fix, the
100×10 concurrent batch from the bug report finishes in ~5s with the
backlog cleanly timing out, vs ~200s wall time and zero interrupts
before.