Convert failedWorkflow input to a Map so nested references resolve

[nikhiln64]

Pull Request type

• Bugfix
• Feature
• Refactoring (no functional changes, no api changes)
• Build related changes
• WHOSUSING.md
• Other (please describe):

NOTE: Please remember to run ./gradlew spotlessApply to fix any format violations.

Changes in this PR

The failure-workflow input placed the raw WorkflowModel POJO under failedWorkflow. The JsonPath provider used by ParametersUtils (JsonSmartJsonProvider with Option.SUPPRESS_EXCEPTIONS) cannot traverse POJOs, so nested references like ${workflow.input.failedWorkflow.workflowId} silently resolved to null — while referencing the whole object appeared to work, because Jackson serialized it on output. Classic silent data loss in failure/compensation workflows.

This PR converts the model to a Map<String, Object> via ObjectMapper.convertValue at the insertion point in WorkflowExecutorOps.terminateWorkflow. The serialized JSON shape is unchanged (Jackson serialization is what made the whole-object case work), so existing consumers of the full object see identical payloads — nested paths just resolve now.

Extended testTerminateWorkflowWithFailureWorkflow to capture the created failure workflow and assert failedWorkflow is a Map with resolvable nested fields. :conductor-core:test green (TestWorkflowExecutor 57/57, TestWorkflowExecutorDecideLoop 2/2); spotlessApply run.

Issue #1164

Alternatives considered

Fixing inside ParametersUtils.getTaskInputV2 (deep-converting any POJO before JsonPath parsing) would repair all such cases at once, but changes evaluation behavior for every workflow input in the system — far riskier than converting at the one known insertion site. Also considered adding a debug log in ParametersUtils when a path resolves to null; left out to keep this PR surgical.

Developed with AI assistance (Claude Code), reviewed and driven by a human.

[nikhiln64]

Note on the red test-harness check: the failing step is "Publish Test Report" (fork PRs' read-only token can't create check runs), not the tests themselves - same pattern is visible on other recent external PRs' CI runs.

[nikhiln64]

@v1r3n the branch is up to date with main now and the CI run is waiting for maintainer approval to start. Could you approve the workflow run when you get a chance? Everything on my side is done.

[nikhiln64]

@v1r3n quick follow up. The branch update queued a fresh CI run that needs maintainer approval again before it can start. Once that runs this should be ready to land since your approval is already in.

[nikhiln64]

@v1r3n no rush on this and I know things get busy. This one has been approved since the middle of July and is just waiting to land, so I wanted to float it back up in case it slipped off the radar. The only red check is the Publish Test Report step, which fails on the fork read only token rather than on the tests themselves, the same pattern visible on other external PRs. I have just brought the branch back up to date with main so it is ready to merge whenever you get a chance, and thanks again for the earlier review.