fix(submit): make maxLine authoritative so the #208 drain test isn't vacuous

[LukasWodka]

Summary

Follow-up to #208 (merged). The adversarial review of #208 caught — after merge — that its streamDisplayAndParse drain regression test is vacuous, and the root cause is a latent footgun in the helper itself.

bufio.Scanner.Buffer(buf, max) sets the token cap to max(max, cap(buf)). streamDisplayAndParse passed a 64 KB initial buffer with maxLine as the max, so any maxLine < 64 KB was silently raised to 64 KB. #208's test used maxLine=1024 with a ~7.5 KB "oversized" line — under the 64 KB floor — so it never tripped bufio.ErrTooLong and the drain branch was never exercised. The test passed even with the drain deleted.

Fix

• Clamp the scanner's initial buffer to maxLine so maxLine is authoritative. Production behaviour is unchanged: it passes 16 MB, so the clamp is a no-op — the initial buffer stays 64 KB and grows on demand exactly as before.
• The test now uses maxLine=4096 with a >4 KB line and a setup guard (len(oversized) > maxLine) against future vacuity.

Verification

• go build ./..., go vet ./..., go test ./... — green; gofmt clean.
• Mutation proof: with this fix in place, removing the io.Copy drain makes TestStreamDisplayAndParse_DrainsPastOversizedLineSoParserSeesBannerFAIL (InsertedRecords=0 — the false exit 9); restoring the drain passes. The test is now a genuine guard for the exact behaviour fix: harden login env-validation, Inf/NaN schema inference, and log-scanner buffer (bug-hunt MED) #208 shipped.

The production drain logic from #208 is correct and unchanged — this is a test-integrity + API-honesty fix.

🤖 Generated with Claude Code

---

Note

Low Risk
Test-hardening and a correctness fix for small maxLine values; production still uses 16 MB with no behavior change to the drain path.

Overview
streamDisplayAndParse now clamps the bufio.Scanner initial buffer capacity to maxLine, because Go’s Scanner.Buffer effective token limit is max(maxLine, cap(initialBuf)) — a fixed 64 KB start buffer meant callers passing maxLine < 64 KB never hit bufio.ErrTooLong even when they intended to.

Production behavior is unchanged: watch still passes displayLineMax (16 MB), so the initial cap stays 64 KB and grows on demand as before. The #208 post-ErrTooLong drain logic is untouched.

The drain regression test now uses maxLine = 4096 with a setup check that the fake tqdm line exceeds that cap, so removing the drain would fail instead of passing vacuously.

^{Reviewed by Cursor Bugbot for commit dbb7f06. Bugbot is set up for automated code reviews on this repo. Configure here.}