Handle multiline comments correctly after target attributes

## Current evidence

`preprocess_target_attrs` in `front/parser/src/import.rs` skips blank lines and lines whose trimmed text starts with `//`, `/*`, `*`, or `*/` while looking for the item controlled by `#[target(...)]`.

That is line-based rather than comment-state-based. For a block comment such as:

```wave
#[target(os="linux")]
/* explanation
ordinary text inside the comment
*/
pub fun selected() {}
```

the first comment line is treated as leading trivia, but the ordinary interior line is not. An inactive target can therefore stop preprocessing inside the comment and leave the following item in the source instead of removing it.

## Scope

- Track multiline-comment state while walking leading trivia after a target attribute.
- Keep comments and blank lines associated with the following target-controlled item.
- Handle ordinary interior block-comment lines and nested block comments consistently with the lexer.
- Preserve source line structure for diagnostics.
- Do not change `#[target(...)]` syntax or lexer comment syntax.

## Completion criteria

- Tests cover active and inactive target attributes followed by multiline comments whose interior lines do not begin with `*`.
- Include a nested block-comment case.
- An inactive attributed item is fully removed after the comment while an active item is preserved.
- Processed output keeps the original line count.

Start in front/parser/src/import.rs at preprocess_target_attrs and compare its comment handling with the lexer’s nested-comment behavior. Add parser tests for active and inactive target attributes followed by ordinary and nested multiline comments, then run the relevant parser tests. Done means inactive items are fully removed, active items remain, and processed output preserves the original line count.

Written by the indexing model from the issue text.