Memory & Leak Detection

I'm preparing code for a **Memory & Leak Detection** audit. Please help me collect the relevant files and diagnostics.

## Memory context (fill in)
- Runtime: [e.g. Node.js 22, Bun 1.1, Chrome/Firefox browser, Deno]
- Framework: [e.g. React 19, Next.js 15, Express, Fastify, plain Node.js]
- Observed symptoms: [e.g. "heap grows from 200MB to 2GB over 24h", "browser tab crashes after 30 min", "OOM kills in production every 3 days"]
- Memory limit: [e.g. "--max-old-space-size=4096", "container has 512MB", "default"]
- When it happens: [e.g. "under load", "after many page navigations", "idle server over time"]
- Known suspects: [e.g. "WebSocket connections", "in-memory cache", "event listeners on DOM"]

## Files to gather

### 1. Components/modules with subscription patterns (highest priority)
- React useEffect hooks with:
  - addEventListener / removeEventListener
  - setInterval / setTimeout (check cleanup)
  - WebSocket connections
  - EventEmitter .on() / .off() subscriptions
  - Observable subscriptions (RxJS, etc.)
  - AbortController and fetch cleanup
- Vue watch/watchEffect with cleanup
- Svelte onMount/onDestroy pairs

### 2. In-memory stores and caches
- Any custom Map, Set, Object, or Array used as a cache or store
- LRU cache implementations (check: is there a max size? Is eviction working?)
- Global singletons that accumulate data over time
- Module-level variables that grow (arrays pushed to, maps added to, never cleared)
- Rate limiter stores, session stores, connection pools

### 3. Event system code
- EventEmitter usage: .on() calls (check every .on() has a matching .off())
- DOM event listeners in server-side code (rare but catastrophic)
- Message queue consumers that buffer messages
- Stream handling: readable/writable/transform streams (are they properly destroyed?)

### 4. Long-running processes
- Background workers, job processors, cron tasks
- WebSocket server connection management (how are disconnected clients cleaned up?)
- File watcher code (fs.watch, chokidar)
- Database connection pool lifecycle

### 5. Closure and reference patterns
- Functions that close over large objects (data, DOM nodes, components)
- Callbacks stored in arrays or maps that are never removed
- Promise chains that hold references to large intermediate results
- Circular references between objects

### 6. Diagnostics (run and include if possible)

```bash
# Node.js heap snapshot (take two, 5 minutes apart, compare)
node --inspect your-app.js
# In Chrome DevTools: Memory tab → Take heap snapshot

# Node.js process memory
node -e "const used = process.memoryUsage(); Object.entries(used).forEach(([k,v]) => console.log(k, (v/1024/1024).toFixed(1) + 'MB'))"

# Check for EventEmitter warnings
# Look for: "MaxListenersExceededWarning" in logs

# Browser: Performance Monitor tab in Chrome DevTools
# Watch: JS heap size, DOM nodes, event listeners count over time
```

## Formatting rules

Format each file:
```
--- components/RealtimeChart.tsx (suspected leak: WebSocket) ---
--- lib/eventBus.ts (module-level EventEmitter) ---
--- lib/cache.ts (in-memory Map, no max size) ---
--- workers/jobProcessor.ts (long-running) ---
--- Heap snapshot comparison (if available) ---
```

## Don't forget
- [ ] For EVERY .on() / addEventListener, check there's a corresponding .off() / removeEventListener
- [ ] For EVERY setInterval, check there's a clearInterval in cleanup/unmount
- [ ] For EVERY new Map() / new Set() at module level, check if entries are ever deleted
- [ ] Include the CLEANUP code (useEffect return, componentWillUnmount, onDestroy) — missing cleanup IS the leak
- [ ] Note the process memory over time if you have monitoring data
- [ ] Check for "MaxListenersExceededWarning" in server logs — it's a direct leak indicator
- [ ] Include any connection pool configuration (max connections, idle timeout)

Keep total under 30,000 characters.