Keep the extracted text one line per source line

[Eljees]

Fixes #1022.

The reported file, on current v3:

$ vale --output=line whatever.proto
whatever.proto:5:4:spelling.english:Did you really mean 'Eror'?
whatever.proto:8:1:spelling.english:Did you really mean 'Eror'?   # source line 7, column 4

coalesce joins a run of line comments into one comment, and the run came out with more lines than the source it maps back to:

• a blank line comment — // with nothing after it — contributed two newlines where every other line contributes one, so it ended its line twice;
• the newline that terminates the line a run is attached to was added or skipped based on whether the run already started with one, rather than on whether that text already ended with one.

Once the extracted text and the source disagree about line counts, adjustAlerts maps an alert to the wrong source line. Hence the line being one too far down, and the column collapsing to 1: the source line it was measured against was past the end, so its padding was zero.

It isn't protobuf-specific — the same file shape in Go reports 7:1 for a comment on line 6.

The part that isn't obvious

Lining the two up on its own broke Rust. /// and //! node content already carries its trailing newline, so the old code skipped the branch that trimmed the space after the delimiter, and that space stayed on every joined line. It was then counted twice — once in the alert's own column, once in lang.Padding — and the two errors cancelled, which is why Rust columns looked right while the text was already a line out.

So the trim is now unconditional, and the space is counted once. testdata/comments/out/1.json shows what that means: " # Arguments" becomes "# Arguments", matching what the author actually wrote after the delimiter.

Checked-in expectations that move

Three golden files change, and every change is one spurious blank line or one leading space disappearing:

• out/0.json, out/5.json — a blank comment line produced two blank lines in the extracted text; now one.
• out/1.json — the same, plus Source losing the blank line it had gained after the first line, plus the leading spaces above.

No line-count expectation in the e2e suite changes: the suite is green as it stands, including lint/rust, cli/two-dirs and fragments/code-to-markup, which are the cases that pinned the old Rust columns. go test ./... is green (units and all 169 e2e scenarios), as are gofmt and go vet.

fragments/blank-comment-line covers both shapes — protobuf with one blank line, Go with two — and fails on current v3 with exactly the offsets from the issue.

AI-assisted (LLM used for drafting); the runs above are mine.

[jdkato]

Thanks — two small things.

attachRun does strings.TrimLeft(run, " "), but appendLine already trimmed every line of the run including the first, so that's dead.

appendLine gives you one line per call only when the input has at most one trailing newline. strings.TrimRight(line, "\n") + "\n" would make the invariant hold unconditionally — a line-scope comment whose content is "text\n\n" still passes the scope test in query.go, and it would slip through as written:

input	output	lines
""	"\n"	1
"text"	"text\n"	1
"text\n"	"text\n"	1
"text\n\n"	"text\n\n"	2

[Eljees]

Addressed both points in 3340f36: attachRun no longer trims a run that appendLine has already normalized, and appendLine now uses strings.TrimRight(line, "\n") + "\n". I added a focused table test including the "text\n\n" case. go test ./internal/lint/code passes.