Typed-conversion code lens silently drops comments

ScriptCodeLensProvider.convertProcessToTyped() replaces the entire process range with formatter output, but unlike the formatting providers it has no commentsPreserved() guard, and the positional comment attacher does not carry comments from the input/output/directive sections.

Converting this process:

process test {
    // comment in input block
    input:
    val id // trailing on input

    script:
    // comment in script block
    "true"
}

produces a replacement that keeps only // comment in script block — both input-block comments are gone. The code lens applies the edit without warning, so the user loses comments with no indication that anything was dropped.

Two things to decide:

• Apply FormattingUtils.commentsPreserved() to the conversion edits and refuse the conversion when comments would be lost, as the formatting providers do.
• Or fix the attacher so the input/output/directive sections carry their comments through the conversion, which is the better outcome if it is feasible upstream.

convertParamsToTyped() has the same shape and no test coverage at all; converted params also lose their @Description comments (a known, accepted limitation of the conversion preview since the LEADING_COMMENTS marker was removed upstream).

Found while reviewing #163, which added the refuse-on-comment-loss guard to the formatting providers but left this sibling path unguarded — it now runs against comment-carrying ASTs for the first time.

Start at ScriptCodeLensProvider.convertProcessToTyped() and compare its conversion edits with the formatting providers' use of FormattingUtils.commentsPreserved(). Review the positional comment attacher for input, output, and directive sections, then inspect convertParamsToTyped() and the discussion from #163. Done means conversion no longer silently loses comments, either by refusing affected edits or preserving them, with test coverage added for both conversion paths.