fix: wrap non-map action results to satisfy Jido.Exec output validation

[Munksgaard]

Ash generic actions (type :action) can return non-map types like strings
or integers. Jido.Exec's output validation pipeline calls Map.split/2
on the result, which raises BadMapError for non-map values.

Fix by adding ensure_map_output/1 function that wraps non-map, non-list
primitives in %{result: value} after convert_to_maps/1 completes. This
ensures generated Jido Actions always return {:ok, map()} as required
by the Jido.Action contract, while preserving correct behavior for
nested resource conversions.

Changes:

• Add ensure_map_output/1 to wrap primitives at top level only
• Preserve existing behavior for Ash resources, lists, and structs
• Add comprehensive tests for string, integer, boolean, atom, and nil results

[mikehostetler]

Wrapping in %{result: value} is the canonical return format that is enforced in jido_action - this is a deep assumption in the ecosystem - so we should stick with that route.

Thanks!

[Munksgaard]

Wrapping in %{result: value} is the canonical return format that is enforced in jido_action - this is a deep assumption in the ecosystem - so we should stick with that route.

Thanks!

You're welcome! I've updated the PR description, title and contents to correctly wrap results in a map (unless it's a list, as there are tests asserting that this format is also okay).

[mikehostetler]

I validated this against current main by cherry-picking 93c133e on top of the merged Jido 2.1 bump.

Good news: the change does fix the default scalar case under Jido.Exec when output_map?: true.

However, it does not fully fix the execution-path bug it describes:

• scalar results still fail under Jido.Exec when output_map?: false
• list results still fail under Jido.Exec, including a plain list of maps

Local repro after cherry-picking this PR onto current main:

• Jido.Exec.run(ScalarMappedAction, %{}, %{}) -> {:ok, %{result: "hello"}}
• Jido.Exec.run(ScalarRawAction, %{}, %{}) -> BadMapError from Map.split/2
• Jido.Exec.run(ListMapAction, %{}, %{}) -> BadMapError from Map.split/2

The relevant Jido path is Jido.Action.Runtime.validate_output/2, which still assumes a map and calls Map.split/2 on the action result.

So this PR is a useful partial fix for the default scalar case, but it is not a complete fix for non-map outputs through Jido.Exec. I would not merge it as the full resolution without either:

1. an integration test that exercises Jido.Exec.run/3, and
2. a decision on the intended behavior for list outputs and output_map?: false scalar outputs.

[Munksgaard]

I validated this against current main by cherry-picking 93c133e on top of the merged Jido 2.1 bump.

Good news: the change does fix the default scalar case under Jido.Exec when output_map?: true.

However, it does not fully fix the execution-path bug it describes:

* scalar results still fail under `Jido.Exec` when `output_map?: false`

* list results still fail under `Jido.Exec`, including a plain list of maps

Local repro after cherry-picking this PR onto current main:

* `Jido.Exec.run(ScalarMappedAction, %{}, %{})` -> `{:ok, %{result: "hello"}}`

* `Jido.Exec.run(ScalarRawAction, %{}, %{})` -> `BadMapError` from `Map.split/2`

* `Jido.Exec.run(ListMapAction, %{}, %{})` -> `BadMapError` from `Map.split/2`

The relevant Jido path is Jido.Action.Runtime.validate_output/2, which still assumes a map and calls Map.split/2 on the action result.

So this PR is a useful partial fix for the default scalar case, but it is not a complete fix for non-map outputs through Jido.Exec. I would not merge it as the full resolution without either:

1. an integration test that exercises `Jido.Exec.run/3`, and

2. a decision on the intended behavior for list outputs and `output_map?: false` scalar outputs.

Good catch. I've updated the PR to address this by adding tests that exercise Jido.Exec.run/3 and decided to wrap output_map?: false results as well.