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.