Bound SummaryParser.buf growth on newline-less log floods (D3)

[saadqbal]

Deferred finding D3 from the v0.8.0 review (release ticket #220). Low severity.

Problem

internal/submit/summary.go's SummaryParser.Feed accumulates bytes into p.buf until it sees a \n. The display side caps an oversized tqdm line via displayLineMax (16 MB) in streamDisplayAndParse (watch.go) and drains the rest, but the drained bytes still flow through the TeeReader into SummaryParser.Feed. So a pathological ingestor emitting many MB of \r-redraws with no \n for the life of a (up to 1h JobWatchTimeout) run makes p.buf grow without the display-side cap applying to the parser.

Fix

Cap p.buf growth: when the partial (newline-less) buffered line passes a ceiling, drop it (and the rest of that line, up to the next \n) so the parser has the same bound the display path does. Mirror displayLineMax — they live in the same submit package, so reference it directly to avoid drift (const parserLineMax = displayLineMax).

A real banner line is tens of bytes; newline-less content past 16 MB cannot be one, so dropping it is safe. After the oversized line finally terminates, the parser resumes normally and still parses the closing banner.

Acceptance

• p.buf stays bounded (≤ parserLineMax) under a multi-MB newline-less flood.
• A real banner arriving after the flood still parses.
• New white-box test in summary_test.go.

Branch → PR into develop. Rolls up under #220.

[LukasWodka]

Closing — fixed and shipped. cli#227 ("Closes #226", merged, on main) landed the exact remedy: SummaryParser.buf is bounded by parserLineMax with a drop-and-resync state on a newline-less flood, plus the TestSummaryParser_BufferBoundedOnNewlinelessFlood regression test. Nothing left to do. (2026-07-11 backlog triage.)