Removed connection pool references from storage and configuration docs.

Configuration.md

@@ -39,7 +39,6 @@ owlbot:
   handler_timeout: 30.0
   storage_dir: "data"
   modules_dir: "modules"
-  pool_size: 4
   log_dir: ""
   webhook_secret: ""
   public_base_url: ""
@@ -53,7 +52,6 @@ owlbot:
 | `handler_timeout` | `30.0` | `OWLBOT_HANDLER_TIMEOUT` | | Maximum seconds a handler can run before it is cancelled. |
 | `storage_dir` | `"data"` | `OWLBOT_STORAGE_DIR` | `-s`, `--storage-dir` | Directory for per-module SQLite database files. Each module gets a `<module_name>.db` file here. Relative paths are resolved from the working directory. |
 | `modules_dir` | `"modules"` | `OWLBOT_MODULES_DIR` | `-m`, `--modules` | Directory for user-written modules. Built-in modules are loaded from the package regardless of this setting. Relative paths are resolved from the working directory. |
-| `pool_size` | `4` | `OWLBOT_POOL_SIZE` | | Maximum SQLite connections per module in the connection pool. Connections are created lazily as needed. |
 | `log_dir` | *(unset)* | `OWLBOT_LOG_DIR` | `-l`, `--log-dir` | Directory for the `owlbot.log` file. When set, logs are written to this directory in addition to stdout. When unset, logs go to stdout only. |
 | `webhook_secret` | *(auto-generated)* | `OWLBOT_WEBHOOK_SECRET` | | Secret token for the webhook URL path (`/webhook/<secret>`). A cryptographically secure value is generated on first run and saved back to the config file automatically. |
 | `public_base_url` | `owncast.url` | `OWLBOT_PUBLIC_BASE_URL` | | Public base URL for generated links (e.g., `"https://owlbot.example.com"`). Set this if Owlbot is hosted on a different domain than your Owncast instance. |

Modules-Storage.md

@@ -1,6 +1,6 @@
 # Modules - Storage
 
-Each module gets its own SQLite database file, isolated from other modules. Storage is accessed through `ctx.storage`. The API is async and handles connection pooling and WAL mode automatically. Each operation auto-commits independently; use `transaction()` when you need atomicity across multiple operations. Queries are written in standard SQL.
+Each module gets its own SQLite database file, isolated from other modules. Storage is accessed through `ctx.storage`. The API is async with a single lazy connection per module. Each operation auto-commits independently; use `transaction()` when you need atomicity across multiple operations. Queries are written in standard SQL.
 
 ## Schema Setup
 
@@ -123,7 +123,7 @@ Never use f-strings or string formatting for SQL parameters. This prevents SQL i
 
 ## Transactions
 
-Each storage operation auto-commits independently. A call to `execute()`, `fetch_one()`, or any other query method acquires a connection, commits on success (or rolls back on failure), and releases the connection immediately. No connection is held between calls.
+Each storage operation auto-commits independently. A call to `execute()`, `fetch_one()`, or any other query method commits on success or rolls back on failure. No transaction state is held between calls.
 
 When multiple operations must succeed or fail together, use the `transaction()` context manager:
 
@@ -136,12 +136,6 @@ async with ctx.storage.transaction():
 
 Outside of a `transaction()` block, each operation is its own atomic unit. A handler that calls `execute()` three times makes three independent commits.
 
-## Connection Pooling
-
-Storage uses a connection pool with lazy creation. Connections are created on-demand up to `pool_size` (default 4, configurable in `config.yaml` under `owlbot.pool_size`). WAL (Write-Ahead Logging) mode is enabled on all connections so concurrent readers and a single writer don't block each other.
-
-The pool is per-module; each module's database has its own pool. Connection management is fully automatic.
-
 ## Error Handling
 
 Storage operations raise `StorageError` on failure: