fix: address memory edge cases in grep context, sort input, and script parsing

[thieman]

Summary

Addresses memory resource gaps identified in valeri.pliskin/memory-edge-cases:MEMORY_GAPS.md (gaps 1, 3, and 5). See main...valeri.pliskin/memory-edge-cases

• Gap 1 — grep context buffer: Add a MaxContextBytes = 512 KiB aggregate byte cap applied per match group to both the before-context sliding window (-B/-C) and the after-context output stream (-A/-C). Before-context evicts oldest lines when the byte ceiling is hit; after-context stops printing context lines. Both counters reset at the start of each new match group. The global executor output limit bounds total output across all groups.

• Gap 3 — sort input size: Lower MaxTotalBytes from 256 MiB to 5 MiB. In a pipeline, N concurrent sort instances each buffer their full input simultaneously with no cross-stage cap — at 256 MiB, a 3-sort chain could consume ~768 MiB. The new limit keeps each instance well-bounded. Error message now includes the limit value and actionable guidance for callers.

• Gap 5 — script size limit: Add interp.ParseScript(script, name string) and interp.MaxScriptBytes = 5 MiB to the interp package. Unlike all other inputs (variables, command substitution, per-line builtins), the script itself previously had no cap inside rshell — it relied entirely on callers. ParseScript enforces the limit before the syntax parser allocates any memory. The CLI execute() now uses this helper. Library callers should use ParseScript rather than calling the underlying syntax parser directly.

Gap 4 — pipeline goroutine depth (documented, not fixed)

Gap 4 (unbounded goroutine count from deep pipelines) is intentionally not addressed here. The constraints:

• Pipelines are parsed left-recursively: a | b | c | d becomes ((a|b)|c)|d. Each | node spawns a goroutine for its left side and runs the right side synchronously, so N pipeline stages produce N−1 simultaneously live goroutines with no enforced limit.
• A semaphore won't work: the pipe creates backpressure — a goroutine holding a semaphore slot blocks waiting for the pipe to drain, while the downstream goroutine it's waiting for can't acquire a slot to start. Deadlock.
• The principled fix (Option C) would flatten the entire pipeline chain into a list of N stages upfront, then execute at most K stages concurrently using a proper goroutine pool connected by pipes. This correctly bounds goroutines to K regardless of pipeline depth, but requires significantly reworking the pipeline execution model in runner_exec.go. The complexity and risk are not proportionate to the benefit at this time.

Test plan

• go test ./... passes (all existing tests green)
• grep -B 1000 with 1 MiB lines stays within the 512 KiB window cap
• sort rejects input > 5 MiB with a descriptive error
• interp.ParseScript rejects scripts > 5 MiB before any parsing occurs
• execute() in the CLI correctly surfaces the size error with exit code 2

🤖 Generated with Claude Code