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

README.md

@@ -1,6 +1,6 @@
 # auth-proxy
 
-A lightweight Go auth proxyway that sits in front of sensitive services (phpMyAdmin, Gitea,
+A lightweight Go auth proxy that sits in front of sensitive services (phpMyAdmin, Gitea,
 uptime kuma) and provides:
 
 - IP-based whitelisting (permanent and temporary via REST API with TTL, stored in SQLite)

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.
+- Persistence across restarts.
-- Fast (O(1) lookup).
+- 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.

docs/security.md

@@ -48,7 +48,7 @@ Each entry records:
 
 Retrieve logs via the `/api/logs` endpoint.
 
-The audit log is automatically rotated to maintain a maximum of 100,000 entries.
+The audit log is automatically rotated to maintain a maximum of 200,000 entries.
 
 ## IP validation