docs: fix typos and update design rationale for SQLite choice

- Correct "proxyway" typo in README
- Rewrite design.md to explain SQLite decision over in-memory map,
  highlighting persistence, ACID transactions, and concurrent read
  support via WAL mode
- Increase audit log rotation limit from 100k to 200k entries

docs/design.md

@@ -94,16 +94,20 @@ For a handful of IPs (dozens at most), SQLite is:
 - Fast (single-file, no network).
 - No external dependencies.
 
-## Why in-memory temporary whitelist?
+## Why not in-memory temporary whitelist?
 
-For a handful of IPs (dozens at most), an in-memory map is:
+We originally considered an in-memory map but switched to SQLite because:
 
-- Simple to implement.
-- Fast (O(1) lookup).
+- Persistence across restarts.
+- ACID transactions.
+- Simple WAL mode for concurrent reads.
+
+For a handful of IPs (dozens at most), SQLite is:
+
+- Simple to deploy.
+- Fast (single-file, no network).
 - No external dependencies.
 
-If you need persistence across restarts, add a disk-backed store later.
-
 ## Why a background cleanup goroutine?
 
 The cleanup goroutine removes expired temporary entries and rotates the audit log.
@@ -118,4 +122,3 @@ may not be available (no host filesystem access).
 ## Why not use Redis?
 
 For our use case, Redis is overkill.
-We chose an in-memory map + periodic cleanup.