Code foldings results are wrong when the endLine ends with `},` Or `);`

rust-analyzer version: 1.86.0 (05f9846 2025-03-31)
rustc version: 1.86.0 (05f9846f8 2025-03-31)
editor or extension: VsCode

code snippet to reproduce:

fn main() {
    test_the_folding_regions_bug(
        SomeBugStuff {
            buggy: Some(Bug),
            ..Default::default()
        },
    );
}

(Notice the comma/simicolon at the end of the lines.)
The lsp reports the following results for the above code snippet

[Trace - 8:03:51 PM] Received response 'textDocument/foldingRange - (609)' in 1ms.
Result: [
    { "startLine": 0, "endLine": 7 },
    { "startLine": 1,  "endLine": 5 },
    { "startLine": 2, "endLine": 4 }
]

But when i remove the comma and the simicolon i get the correct results.

[Trace - 8:07:12 PM] Received response 'textDocument/foldingRange - (642)' in 1ms.
Result: [
    { "startLine": 0, "endLine": 7 },
    { "startLine": 1,  "endLine": 6 },
    { "startLine": 2, "endLine": 5 }
]

The reason that no one did notice this bug until now is that vscode uses the textmate foldingMarkers altogether with the foldingRange.
But iam writing a custom lsp client and want to be able to get folding ranges without using textmate.

Start with the rust-analyzer implementation of the LSP textDocument/foldingRange request and reproduce the supplied Rust snippet, comparing results with and without the trailing comma and semicolon. Done means the reported folding ranges end at the expected lines for the nested struct and function call, without relying on VS Code TextMate folding markers.