docs: state the SQLite floor without a rationale

Review found the previous edit attributed the 3.35 floor to
RETURNING, which the code never uses. The floor is the oldest
server version the adapter's startup check accepts (201fd33),
not a single-feature requirement, so the entry now states the
supported version without inventing a reason.

Author: cardmagic

docs/research/solid_queue.md

@@ -526,7 +526,7 @@ Source: [Cloudflare Durable Objects overview](https://developers.cloudflare.com/
 - Solid Queue findings are tied to v1.6.0. Earlier releases did not have all current async/fiber supervision and concurrency finalization behavior.
 - PostgreSQL documentation inspected was current PostgreSQL 18 documentation. `SKIP LOCKED` has existed since PostgreSQL 9.5, but Solid Objects supports PostgreSQL 14 and newer.
 - MySQL documentation inspected was MySQL 8.4. Solid Objects supports MySQL 8.0 and newer with InnoDB.
-- SQLite documentation inspected covers current SQLite behavior. Solid Objects requires SQLite 3.35 or newer for `RETURNING` support.
+- SQLite documentation inspected covers current SQLite behavior. Solid Objects supports SQLite 3.35 or newer, the oldest server version the adapter accepts.
 - Rails documentation and source inspected cover Rails 8.1. Solid Objects requires Rails 7.1 or newer. Rails 8 changed the SQLite adapter's default write transaction from deferred to immediate, and the test suite also passes on Rails 7.1 and 7.2 with the deferred default. Rails 7.0 stays out of range because its SQLite adapter requires sqlite3 1.4, and the busy-handler control this gem depends on arrived in sqlite3 2.x.
 - Orleans documentation describes current Orleans behavior, not a compatibility promise for this Ruby implementation.
 - `LISTEN/NOTIFY` and Action Cable are optimizations and delivery channels, never durable truth.