Add size limits to prevent context overflow in large repos

[JordanCoin]

Summary

This PR keeps codemap hooks/MCP useful while making them safe on large repos.

Existing fix (kept)

• Session-start hook uses adaptive depth based on repo size:
  • >5000 files -> depth 2
  • >2000 files -> depth 3
  • otherwise depth 4
• Hook + MCP get_structure enforce 60KB max output (~15k tokens, <10% of context)
• Truncation is clean at line boundaries with a helpful message

Additional hardening in this PR

• Added shared limits package (limits/) so hook + MCP use one source of truth for:
  • output budget (60KB)
  • adaptive depth thresholds
• Daemon now skips dependency graph build on very large repos (>5000 files) to avoid startup CPU/memory spikes
• Daemon now always writes .codemap/state.json (even when dep graph is unavailable), so hooks still get file_count + session event context
• ReadState now accepts stale state if daemon PID is still alive (avoids unnecessary expensive rescans after idle periods)
• Hook hub lookup no longer falls back to heavy fresh graph builds when daemon is already running but dep data is unavailable
• Session-start now:
  • waits briefly for daemon state (small warmup window)
  • uses conservative depth when file count is unknown
  • uses lightweight git diff output for large/unknown repos instead of full codemap --diff
• MCP get_structure now:
  • accepts optional depth
  • defaults to adaptive depth when omitted
  • reuses daemon hub data when available
  • skips expensive hub analysis on very large repos and prints a note

Problem

Large repos (10k+ files) could produce massive startup output and expensive repeated analysis:

• Hook output goes into Claude “Messages” context (competes directly with conversation history)
• Large tree output could consume context immediately
• Repeated fallback graph scans could be expensive when daemon state was missing/stale

Why this matters

Hooks need to be context-aware and resource-aware:

• bounded output
• graceful degradation on large repos
• avoid repeated heavy computation in background hook flows

Test results

• go test ./... passes
• Stress-tested on synthetic ~10k-file repo:
  • session-start output remained small (no runaway output)
  • daemon state remained usable after idle
  • pre-edit hook significantly faster with daemon vs no daemon

Behavioral note

On very large repos, hub/dependency analysis is intentionally deferred in hook/session-start flows unless explicitly requested via dedicated tooling (get_hubs, etc.).