Improve concurrent database access

[JanJakes]

Summary

Reduces lock contention under concurrent access by avoiding unnecessary write locks for read-only queries.

1. Skip the wrapper transaction for SELECT statements. A standalone SELECT translates to a single SQLite query, so the implicit autocommit transaction provides sufficient consistency — no explicit BEGIN/COMMIT needed.
2. Use deferred BEGIN for other read-only wrapper transactions. SHOW and DESCRIBE queries still use a wrapper transaction (they may translate to multiple SQLite queries), but now use a deferred BEGIN (SHARED lock) instead of BEGIN IMMEDIATE (RESERVED lock).

Background

The wrapper transaction previously used BEGIN IMMEDIATE for all queries, including read-only SELECTs. This acquired a RESERVED (write) lock on every query — but SQLite only allows one RESERVED lock at a time. Under concurrent load (e.g., multiple PHP-FPM workers handling requests simultaneously), all processes competed for the single write lock. When the 10-second busy timeout was exceeded, SQLite returned SQLITE_BUSY ("database is locked", error 5).

SHARED locks, acquired by a deferred BEGIN, are compatible with RESERVED locks — multiple readers can proceed concurrently alongside an active writer.

Fixes #318