refactor(checks)!: new 'Interact' API

[mattbit]

Major renaming and API change:

• InteractionSpec is now simply InteractionInteract. This is the main dynamic interface. It extends InteractionSpec which is its abstract definition (with generate method).
• The old Interaction becomes InteractionRecord to signal that it is an immutable realization of the Interaction Interaction remains a static representation of a single exchange, but it is now only used internally and not exposed. E.g. Scenario only accepts InteractionSpec/Interact objects and no Interaction.

Scenarios and testcases now only see InteractionSpec, i.e. the dynamic version. However, the Check logic receives a static Trace composed of Interactions which are guaranteed to be complete (no dynamic values, no mutable fields).

I also regrouped the interactions and trace objects under the checks.core.interaction submodule. Before, definitions were split across checks.core.interaction, checks.interaction, and checks.core.trace.

This replaces #2269 by maintaining the two distinct classes (dynamic vs frozen).

[henchaves]

I think we are still giving much attention to the usage of InteractionRecord as a Scenario component. We need to focus on using only Interaction wherever it's possible.

The manual instantiation of InteractionRecord should be limited for when creating a Trace:

trace = Trace(interactions=[InteractionRecord(inputs="test", outputs="result")])

Having scenarios with mixed InteractionRecord and Interaction is not nice, and it's kind of the same thing of having InteractionSpec/Interaction - so what is the goal of this PR?

# ❌ BAD
scenario = Scenario(sequence=[
   InteractionRecord(inputs="test", outputs="result"),
   Interaction(inputs="hello", outputs="word")
])

If you think it's appropriate, I would make only Interaction as a Scenario component (and Check, of course), and if needed, users could map InteractionRecord to Interaction using an API such as Scenario.from_records()

Overall, the implementation is well done. Did many tests with different scenarios and all of them worked well.

[mattbit]

@henchaves should have addressed all comments, except for the union which didn't feel necessary at this stage.

[mattbit]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a significant and valuable refactoring of the interaction APIs, clarifying the distinction between dynamic specifications (Interact) and static records (Interaction). The code changes are well-executed and the new structure is more intuitive. However, the documentation (README, CODEMAP) and some docstrings have not been fully updated to reflect these changes, leading to inconsistencies and incorrect examples. I've pointed out several places where class names like Interact, InteractionSpec, and Interaction are used incorrectly. Addressing these documentation issues will be crucial for users to understand and adopt the new API.

[henchaves]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a major and beneficial refactoring of the interaction API, clarifying the distinction between dynamic interaction specifications (Interact) and static interaction records (Interaction). The renames from InteractionSpec to Interact and BaseInteractionSpec to InteractionSpec improve clarity. The code reorganization into the checks.core.interaction submodule is logical. The changes are extensive but appear to be consistently applied across the codebase, including documentation and tests. I've found a couple of minor issues in the documentation that should be addressed.

[henchaves]

LGTM