FIX: remove type suppression comments from MessagePiece.to_message() via TYPE_CHECKING

[Copilot]

Description

Removes three type-suppression comments (# type: ignore[name-defined], # noqa: F821) from MessagePiece.to_message() in pyrit/models/message_piece.py by using the TYPE_CHECKING guard that already exists in that file.

The Score import two lines below already uses this exact pattern — this change makes Message consistent with it.

What changed:

• Added from pyrit.models.message import Message to the existing TYPE_CHECKING block (alongside Score). This makes Message visible to mypy/pyright/IDEs with no runtime cost and no circular import.
• Removed all suppression comments from the to_message() return type annotation and return statement. The from __future__ import annotations (line 4) enables PEP 563 postponed evaluation, so the bare name Message in the signature is a valid forward reference resolved by the TYPE_CHECKING import.
• Kept the local runtime import from pyrit.models.message import Message inside the method body. This is the necessary exception to the "no inline imports" rule documented in the style guide: it resolves the circular import at runtime since Message is not imported at module level.

Tests and Documentation

No behavioral change — purely a type annotation / suppression-comment cleanup. No new tests or documentation required.

JupyText not applicable (no notebook changes).

[spencrr]

@copilot

Does linting pass?
Does this import within function make sense/follow best practice?
Do you think this is the best solution (if so, why?)
Can you please update PR description to follow the template in the repo?

[Copilot]

@copilot

Does linting pass?
...

Linting: Yes, linting passes. The style guide explicitly allows local imports inside functions as the documented exception for circular dependency resolution: "The only exception is breaking circular import dependencies, which should be rare and documented." Ruff's PLC0415 (import-outside-toplevel) is not in the project's selected rule set, and the TCH rules (which enforce moving imports into TYPE_CHECKING) are satisfied since Message is now correctly placed there.

Does the local import inside the function make sense? Yes — this is the canonical two-layer pattern for TYPE_CHECKING + circular imports in Python:

• The TYPE_CHECKING import (if TYPE_CHECKING: from pyrit.models.message import Message) makes Message visible to static analysis tools and IDEs without executing at runtime (avoiding the circular import).
• from __future__ import annotations (already on line 4) means the -> Message return type in the signature is treated as a string at runtime, so Python never tries to resolve it.
• The local runtime import inside the method body is still needed because Message is not available at module level at runtime — it must be imported lazily on first call.

This is exactly the same pattern already used for Score two lines above in the same TYPE_CHECKING block.

Is this the best solution? Yes. The alternatives are worse:

• Adding a top-level import would create a circular import at module load time.
• Keeping the suppression comments is a code smell that breaks type checker and IDE resolution.
• Using a string annotation (-> "Message") would work but is redundant given from __future__ import annotations is already enabled.

The TYPE_CHECKING pattern is the Python docs-recommended approach for this exact scenario.

PR description has been updated to follow the repo template (commit 6c6f81b).