feat: miller column browser, offline cache, search, breadcrumbs

- Dynamic miller column sizing with flexbox layout
- Root column (160px), middle slices (48px), active column (flex)
- Auto-scroll browser to rightmost column on navigation
- Offline indicator UI and IndexedDB cache integration
- /api/documents endpoint for client-side document caching
- Breadcrumb navigation in document content area
- FTS5 search with SQLite virtual table
- Client-side Mermaid and KaTeX rendering via CDN
- Deep sample content (advanced-topics/raft-deep-dive)
- Border removal (only search button keeps radius)
- Full viewport layout with proper borders between sidebar/content

content/advanced-topics/distributed-systems/consensus-algorithms/raft-deep-dive/configuration.md

@@ -0,0 +1,37 @@
+# Raft Configuration
+
+Configuration options for running a Raft cluster in production.
+
+## Cluster Size
+
+For fault tolerance with `f` failures, you need `2f + 1` nodes:
+
+- 3 nodes: tolerates 1 failure
+- 5 nodes: tolerates 2 failures  
+- 7 nodes: tolerates 3 failures
+
+## Election Timeout
+
+The election timeout should be:
+
+- At least 10x the network round-trip time (RTT)
+- Typically 150-300ms in a single datacenter
+- 500ms-2s across regions
+
+## Heartbeat Interval
+
+Set to roughly 1/3 to 1/10 of the election timeout:
+
+```
+heartbeat_interval = election_timeout / 3
+```
+
+## Log Compaction
+
+Configure snapshot creation when the log grows too large:
+
+| Threshold | Description |
+|-----------|-------------|
+| 10,000 entries | Minimum for frequent writes |
+| 100MB | Size-based threshold |
+| Daily | Time-based for low-write workloads |

content/advanced-topics/distributed-systems/consensus-algorithms/raft-deep-dive/index.md

@@ -0,0 +1,28 @@
+# Raft Deep Dive
+
+A detailed look at the Raft consensus algorithm.
+
+## How Raft Works
+
+Raft uses a leader-follower model where one node is elected as the leader and all other nodes are followers.
+
+## Key Components
+
+1. Leader Election
+2. Log Replication
+3. Safety
+
+## Election Process
+
+When a follower doesn't hear from the leader for a timeout period, it increments its term and starts an election.
+
+```mermaid
+graph TD
+    A[Follower] --timeout--> B[Candidate]
+    B --votes received--> C[Leader]
+    C --heartbeat--> A
+```
+
+## State Machine
+
+The state machine applies committed log entries to produce the same output on all nodes.

content/advanced-topics/distributed-systems/consensus-algorithms/raft-deep-dive/performance-tuning.md

@@ -0,0 +1,44 @@
+# Raft Performance Tuning
+
+Optimizing Raft for high-throughput workloads.
+
+## Batch Processing
+
+Batch multiple client requests into a single AppendEntries RPC:
+
+```go
+// Example: batch size of 100 entries
+batchSize := 100
+for i := 0; i < len(requests); i += batchSize {
+    end := min(i+batchSize, len(requests))
+    batch := requests[i:end]
+    leader.AppendEntries(batch)
+}
+```
+
+## Pipeline Optimization
+
+Allow the leader to pipeline log entries without waiting for each Ack:
+
+- Set `max_inflight_entries` to 100-1000
+- Use a sliding window for acknowledgments
+- Retry only unacknowledged entries
+
+## Read Index Optimization
+
+For read-heavy workloads, use **read index** instead of log replication:
+
+1. Client sends read request to leader
+2. Leader commits a heartbeat (no-op) entry
+3. Once committed, leader serves read from state machine
+4. Followers can serve stale reads directly
+
+## Benchmarks
+
+Typical throughput on a 5-node cluster:
+
+| Workload | Throughput | Latency (p99) |
+|----------|-----------|---------------|
+| Writes only | 50K ops/sec | 5ms |
+| Mixed (80/20) | 100K ops/sec | 3ms |
+| Reads only | 500K ops/sec | 0.5ms |