v0.1.0-alpha.76

feat: bash output head+tail truncation + 5 MB hard ceiling (alpha.76)

Pattern lifted from Claude Code's EndTruncatingAccumulator. Two
layers of overflow protection on the foreground bash session:

LAYER 1: HARD CEILING IN STREAM CALLBACKS (5 MB per stdout/stderr)
  Above 5 MB, stream callbacks stop appending. Prevents the WebView
  from OOMing on a runaway command (npm install on a fresh repo can
  emit 10+ MB of progress lines). Tradeoff: content dropped silently
  in the runaway case, but the alternative is a crash.

LAYER 2: HEAD+TAIL TRUNCATION AT RESULT RETURN (100 KB total)
  The model never benefits from a 5 MB log. truncateStream() returns
  the first 60 KB + last 40 KB with an explicit marker:
    [...4.8 MB truncated; 5.0 MB total. Run a tighter command
     (head/tail/grep) if you need the missing slice...]
  Snaps to newline boundaries so we don't slice in the middle of a
  log line. Head bias (60K vs 40K) preserves errors-at-start more
  aggressively than tail noise.

Why head AND tail, not just tail: errors often surface early
(syntax errors, dep resolution failures) and conclude late (test
summaries, exit codes). Pure-tail truncation drops the 'why' and
keeps only the conclusion; head+tail keeps both.

Why no disk-streaming yet: adds file management, cleanup, and a
'/tmp/<id>.txt' path the model would have to read_file separately
to see the truncated middle. Truncation alone closes the OOM hole
and the model's-context-bloat hole — disk dumping is marginal
extra value. If users actually hit the truncation marker often
enough that the missing middle bites, that's the signal to layer
disk-streaming on top.

Watchdog (stall detection on a long-running command) deferred too
— qcode's existing 6-min foreground cap + run_in_background:true
escape hatch handles the dev-server / long-build case already.