Mutating a rule so that a custom property declaration is immediately followed by a comment node, then stringifying, produces CSS that loses the comment on re-parse:

let css = postcss.parse("a{--x:red}")
css.first.append(postcss.comment({ text: "note" }))

css.toString()          // => "a{--x:red/* note */}"
postcss.parse(css.toString()).first.nodes.length // => 1, the comment is gone

The stringifier skips trailing comment siblings when deciding whether the last real child needs a terminating ;. That is fine for normal declarations, because the parser tokenizes a following /* as a separate comment. But a custom property keeps everything up to the next ; or } as its value, so without the semicolon the comment is folded into the value and the comment node disappears. The same class of bug was fixed for childless at-rules in #2115; this is the declaration counterpart.

The fix emits the semicolon when a custom property still has following siblings, right next to the existing at-rule check in pushBody. Naturally parsed CSS is unaffected: a custom property can only be followed by a separate comment sibling if the source already had a ; there (otherwise the comment is part of the value), and that case already sets raws.semicolon.

Tested with two new cases in test/stringifier.test.js covering append() and after(), both asserting the output and that it re-parses back to decl,comment. Full pnpm test (unit, lint, types, integration, size) is green.