fix(e2ebench): use digit-only cut when parsing the hunk-header new-side start line

[HUQIANTAO]

Summary

changedLineSet parses the @@ -a,b +c,d @@ hunk header to learn the new-side starting line. The old shape used a comma-OR-space cut that silently mis-parses malformed headers — the next + line then registers under line 0, which is invalid.

Fix

Replace the comma-OR-space cut with a digit-only cut. Malformed headers now fail closed (previous newLine kept, no invalid line 0 attribution). The happy paths produce the same integer they did before; the fix is strictly for the malformed case.

Test plan

• go build ./… passes.

[esengine]

Thanks for hardening the hunk-header parse — the digit-only cut is the right instinct. Two things to fix before this can land:

1. lint is red. The if _, err := fmt.Sscanf(...); err != nil { } leaves an empty branch, which staticcheck flags (SA9003). Either drop the error check entirely (the old code intentionally ignored it with _, _ =) or actually do something in the branch.

2. The comments are way over the repo limit. This repo's rule is: default to no comment, one line only when the why is non-obvious (block comments cap at 3 lines). The ~40-line narrative explaining the old behavior reads as commit/PR-description material, not source. Please cut it to at most a single line — something like // digit-only cut: a count header is digits before the comma/space.

The logic change itself is fine. Trim the comment block and fix the empty branch and I'll merge.

[HUQIANTAO]

Thanks for the review. Both points addressed in 699deea:

1. SA9003 (empty branch) — removed the if _, err := fmt.Sscanf(...); err != nil { } branch entirely. The "fail closed" behaviour is preserved by Go's Sscanf: when the parse fails, the destination argument is left unchanged, so the next + line re-uses the last newLine counter — which is exactly the desired behaviour for a malformed hunk header. The Sscanf call now uses the same _, _ = discard pattern as the original pre-PR code.

2. Comment length (3-line cap) — the 40-line narrative is gone; replaced with a single line: // Digit-only cut: malformed headers (e.g. + "" + ) fail closed. That keeps the @@ header comment (pre-existing) and the rationale on a single follow-up line.

Verified locally:

• go build ./... ✅
• go vet ./... ✅
• staticcheck ./cmd/e2ebench/... ✅ (exit 0, no SA9003)

Diff is +8 / -3 against the parent commit. Please re-check when you have a moment.

[HUQIANTAO]

Quick correction: zsh mangled one backtick expression in the previous comment, so the in-source comment line came out garbled. The actual line in 699deea is:

// Digit-only cut: malformed headers (e.g. `@@ +abc @@`) fail closed.

The two @@ segments and the literal backticks render correctly in the source file. No code change needed — just a heads-up that the previous comment had a display glitch, not a code issue.

[HUQIANTAO]

Hi @esengine — 谢谢 review。已经在 699deea 修了两个点：

1. SA9003：直接去掉了 if _, err := fmt.Sscanf(...); err != nil { } 的空分支。Sscanf 失败时 destination 保留旧值，下一行 + 会复用上一个 newLine counter — 这正是 malformed header 想要 fail-closed 的行为。改回原始的 _, _ = 丢弃模式。
2. Comment 长度：40 行的 narrative 删了，缩成单行 // Digit-only cut: malformed headers (e.g. + "+@@ +abc @@ + ") fail closed.`。

本地 go build ./... / go vet ./... / staticcheck ./cmd/e2ebench/... 都过了。麻烦再过一眼 🙏