Add approximate heap/memory tracker for ingested logs (ticket 011)

Tracks a running total of ingested log bytes (approximated as each
log's raw UTF-8 text length), incremented on ingest and decremented
in evict_excess_logs when a log is dropped. Exposed via StatsDto's
new approx_bytes_total field on GET /api/stats, and displayed in
NavMenu's stats panel formatted with toLocaleString() (comma
separators).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XFUNZwCvz3kcod3352ZR2o

src/dto.rs

@@ -47,6 +47,19 @@ pub struct StatsDto {
     pub last_sequence: Option<u64>,
     pub first_timestamp_ms: Option<i64>,
     pub last_timestamp_ms: Option<i64>,
+    /// Ticket 011: a running, *approximate* estimate of the in-memory heap
+    /// held by currently-ingested logs, in bytes. "Approximate" because it
+    /// only counts each `IngestedLine::text`'s UTF-8 byte length — it does
+    /// not account for `String`'s allocator overhead/capacity slack, the
+    /// `BTreeMap`/`IndexKey` node overhead the text is stored under, or any
+    /// derived data (bucket values, params) the line produces elsewhere in
+    /// the index. That's judged the best cheap proxy for "how much memory is
+    /// this log's text costing us": it's O(1) to compute per log (`text.len()`,
+    /// already an interned byte count for UTF-8 `String`), moves in lockstep
+    /// with the dominant cost (raw log text, which is usually much larger
+    /// than the fixed per-entry bookkeeping), and needs no per-entry
+    /// bookkeeping beyond what eviction already tracks.
+    pub approx_bytes_total: u64,
 }
 
 #[derive(Debug, Deserialize)]