no-issue: Infer types in place of Class<T> on Steps interface

[ricardozanini]

Many thanks for submitting your Pull Request ❤️!

What this PR does / why we need it:
We missed the transformation interfaces inference on the other PR (#1219)

Special notes for reviewers:

Additional information (if needed):

[Copilot]

Pull request overview

This PR updates the fluent Func DSL Step chaining API to infer lambda input types at runtime (instead of requiring Class<T> arguments), and adjusts executor tests to use the inferred-type overloads.

Changes:

• Update Step chaining methods (when, exportAs, outputAs, inputFrom) to use ReflectionUtils.inferInputType(...) and pass inferred classes into the underlying builders.
• Switch several Step overloads to accept serializable functional interfaces to enable SerializedLambda-based inference.
• Update data-flow transformation helper tests to remove explicit Class<T> parameters and add explicit lambda parameter types where needed.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
experimental/lambda/src/test/java/io/serverless/workflow/impl/executors/func/FuncDSLDataFlowTransformationHelpersTest.java	Updates tests to use inferred-type DSL overloads and explicitly typed lambda parameters for context-aware functions.
experimental/fluent/func/src/main/java/io/serverlessworkflow/fluent/func/dsl/Step.java	Adds runtime type inference for chained transformations/conditions and updates method signatures to use serializable functional interfaces.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

There are stray characters in this Javadoc type parameter description (ßßß). This will show up in generated docs and should be removed.

Suggested change

	* @param <T> the task result typeßßß
	* @param <T> the task result type