Begin post-v1.0.1 protocol and runtime improvements

docs/ARCHITECTURE.md

@@ -379,7 +379,7 @@ Storage is abstracted by `DbPool`.
 |---|---|---|
 | SQLite memory | `sqlite-in-memory` | default, process-local, ephemeral |
 | SQLite disk | `sqlite-in-disk` | persisted SQLite file at `db_path` |
-| Valkey | `valkey` | Valkey-compatible session store |
+| Valkey | `valkey` | Valkey-compatible session store utilizing thread-safe connection pooling |
 
 The storage layer must support:
 
@@ -389,7 +389,7 @@ The storage layer must support:
 - delete expired sessions
 - report statistics
 
-`valkey` mode reads `CHRONOSEAL_VALKEY_ADDR`, defaulting to `127.0.0.1:6666`. If connection setup fails, the current implementation logs a warning and falls back to in-memory SQLite.
+`valkey` mode reads `CHRONOSEAL_VALKEY_ADDR`, defaulting to `127.0.0.1:6666`. It establishes a connection pool using `r2d2` and the `redis` client crate. Session IDs are indexed using native Valkey sets (`sessions:ids`) to minimize overhead and avoid lock contention, while individual sessions are persisted with a native TTL (`SET ... EX`) matching their expiration times. If connection setup fails, it logs a warning and falls back to in-memory SQLite.
 
 ## Metrics and Observability
 

docs/DEPLOYMENT.md

@@ -178,13 +178,63 @@ sudo mkdir -p /var/lib/chronoseal
 sudo chown -R chronoseal:chronoseal /var/lib/chronoseal
 ```
 
-For Valkey:
+For Valkey / Redis:
+
+ChronoSeal expects a running Valkey or Redis instance when `db_type` is set to `valkey`.
+
+### 1. Installing Valkey or Redis
+To install Valkey (the recommended open-source option) or Redis on Linux:
+
+* **Valkey (Debian/Ubuntu)**:
+  ```bash
+  sudo apt-get install -y valkey-server
+  ```
+* **Redis (Debian/Ubuntu)**:
+  ```bash
+  sudo apt-get install -y redis-server
+  ```
+
+### 2. Local Setup and Startup
+By default, ChronoSeal searches for Valkey/Redis on `127.0.0.1:6666`. 
+
+You can start a local instance manually:
+```bash
+# Start Valkey on port 6666
+valkey-server --port 6666 --bind 127.0.0.1
+# Or start Redis on port 6666
+redis-server --port 6666 --bind 127.0.0.1
+```
+
+Or run it via Docker:
+```bash
+# Run Valkey container mapping host port 6666 to container port 6379
+docker run -d --name chronoseal-valkey -p 6666:6379 valkey/valkey:latest
+```
+
+### 3. Service Configuration
+Configure the environment variables to point ChronoSeal to your instance:
 
 ```bash
 export CHRONOSEAL_DB_TYPE=valkey
 export CHRONOSEAL_VALKEY_ADDR=127.0.0.1:6666
 ```
 
+#### Providing Credentials & SSL/TLS
+If your Valkey/Redis server requires authentication or secure TLS/SSL, include them directly in the `CHRONOSEAL_VALKEY_ADDR` connection URL:
+
+* **Password Only**:
+  ```bash
+  export CHRONOSEAL_VALKEY_ADDR=redis://:your_password@127.0.0.1:6666
+  ```
+* **Username & Password**:
+  ```bash
+  export CHRONOSEAL_VALKEY_ADDR=redis://your_username:your_password@127.0.0.1:6666
+  ```
+* **Secure Connection (SSL/TLS)**: Use the `rediss://` scheme prefix:
+  ```bash
+  export CHRONOSEAL_VALKEY_ADDR=rediss://your_username:your_password@secure-valkey-host.example.com:6379
+  ```
+
 If Valkey connection setup fails, the current implementation logs a warning and falls back to in-memory SQLite.
 
 ## systemd

docs/TESTING.md

@@ -2,14 +2,14 @@
 
 ChronoSeal maintains a rigorous, security-first test suite focused on cryptographic correctness, deterministic server ↔ WASM parity, mutation engine integrity, replay resistance, tampering detection, behavioral validation, and storage reliability.
 
-As of **v0.6.1**, the project contains **89 passing tests** across the server, WASM, and shared protocol crates.
+As of **v0.6.1**, the project contains **93 passing tests** across the server, WASM, and shared protocol crates.
 
 | Crate               |  Tests |
 | ------------------- | -----: |
-| `chronoseal-server` |     30 |
+| `chronoseal-server` |     33 |
 | `chronoseal-wasm`   |     24 |
-| `shared`            |     35 |
-| **Total**           | **89** |
+| `shared`            |     36 |
+| **Total**           | **93** |
 
 ---
 
@@ -55,6 +55,7 @@ test_toml_parses_db_type_kebab_case
 test_init_db_pool_sqlite_in_memory
 test_init_db_pool_sqlite_in_disk
 test_init_db_pool_valkey_compat_mode
+test_valkey_store_operations
 ```
 
 ---
@@ -162,14 +163,22 @@ test_validate_mouse_require_activity_toggle
 Storage tests verify:
 
 * SQLite in-memory operation
-* SQLite disk-backed operation
-* Valkey compatibility mode
+* SQLite disk-backed operation & pool concurrency
+* Valkey compatibility mode & pool concurrency operations
 * Session CRUD behavior
 * Expiration cleanup
 * Runtime statistics reporting
 
 These tests ensure storage implementations remain interchangeable without affecting protocol behavior.
 
+Example tests:
+
+```text
+test_sqlite_pool_concurrency
+test_valkey_pool_concurrency
+test_valkey_store_operations
+```
+
 ---
 
 ## 7. VM Core
@@ -217,7 +226,7 @@ test_rejects_truncated_instruction
 
 # Server Test Coverage (`chronoseal-server`)
 
-The server crate currently contains **30 tests** covering:
+The server crate currently contains **33 tests** covering:
 
 * Configuration
 * Runtime initialization
@@ -256,7 +265,7 @@ These tests ensure browser-generated commitments remain consistent with server e
 
 # Shared Crate Coverage (`shared`)
 
-The shared crate currently contains **35 tests** and represents the core protocol implementation used by both server and browser runtimes.
+The shared crate currently contains **36 tests** and represents the core protocol implementation used by both server and browser runtimes.
 
 Coverage includes:
 
@@ -303,6 +312,7 @@ test_invalid_positions_wrap_deterministically
 ```text
 test_fuzz_style_random_program_bytes_do_not_diverge
 test_performance_smoke_mutation_execution
+test_vm_instruction_budget_soft_cap
 ```
 
 ---
@@ -377,7 +387,7 @@ Planned enhancements include:
 
 ChronoSeal's testing strategy is centered on preserving deterministic behavior, cryptographic correctness, and protocol integrity.
 
-The current suite of **89 tests** provides broad coverage across:
+The current suite of **93 tests** provides broad coverage across:
 
 * Session security
 * Heartbeat validation

docs/THREAT_MODEL.md

@@ -106,6 +106,23 @@ Expected result:
 - ChronoSeal does not claim complete prevention
 - additional application-level controls are required
 
+## Attacker Classification Boundaries
+
+### Protected
+*   **Commodity Scrapers:** Simple HTTP clients (`curl`, Python `requests`, Go HTTP clients) that cannot execute JavaScript or WebAssembly.
+*   **Simple Replay Attackers:** Intercepted heartbeat payloads cannot be reused because of the strict hash-chain sequencing and salt rotation.
+*   **Signature Forgers:** Heartbeats without the session's private key will fail Ed25519 verification.
+
+### Partially Protected
+*   **Headless Automation (Puppeteer, Playwright):** Attackers must load the WASM runtime, execute the VM instructions, calculate gene mutations, and simulate realistic human mouse interactions. This significantly increases CPU and system memory overhead, reducing the scale of bot operations.
+*   **Stealth Automation Frameworks:** Advanced frameworks must maintain state sync across multiple heartbeat cycles, exposing them to timing detection.
+
+### Unprotected
+*   **WASM Key Extraction:** A reverse engineer with full browser process control can extract the private key from WASM memory.
+*   **Malware Operators:** Keyloggers, screen scrapers, or memory dumpers operating at the OS level are outside the application trust boundary.
+*   **MITM Interceptors (without TLS):** Plaintext traffic can be intercepted. (TLS termination is assumed).
+*   **Insiders / Storage Tampering:** Attackers with direct write access to the SQLite database or Valkey instance can forge or hijack active session states.
+
 ## Attack Vectors and Mitigations
 
 ### Replay