Action Flows: reconcile validation-error response shape (422 vs 406)

[marioserrano09]

Summary

Part of #79.

Validation-error responses have two different shapes depending on entry point:

• Plain REST CRUD writes (client.crud(path).create()/update()): HTTP 422 with an ErrorResult body (RestApiExceptionHandler.handleValidationError).
• Action-framework path (SaveRemoteAction/SaveFlowRemoteAction via ApplicationMetadataController.executeAction): HTTP 406 wrapped inside an ActionExecutionResponse.

Problem

This was flagged as a latent bug to reconcile before shipping Phase 4 CRUD parity actions, but Phase 4 shipped without addressing it (documented as an explicit open item in the d03b14c5 commit message). Now that SaveRemoteAction exists side by side with plain REST CRUD for the same entity, the same frontend form can hit either shape depending on which path an app wires up — this is a live inconsistency, not a hypothetical one anymore.

Proposed work

• Pick one shape (422/ErrorResult is the more idiomatic REST convention; the Action-framework's 406/ActionExecutionResponse is more consistent with every other action response).
• Migrate the other entry point to match, or make ActionExecutionResponse carry an ErrorResult-compatible validation payload if 406 is kept for other reasons.
• Update SDK error handling (DynamiaApiError) and any Vue-side form error rendering that currently only understands one shape.

References

• RestApiExceptionHandler.handleValidationError
• ApplicationMetadataController.executeAction
• docs/design/SERVER_DRIVEN_ACTION_FLOWS.md §7.6 point 3, §9

[marioserrano09]

Resolved on `feature/action-flows` (commits 83150fe, a7849b0) per Mario's decision: standardize on 422 + ErrorResult in both entry points.

`ApplicationMetadataController.executeGlobalAction`/`executeEntityAction` now return a genuine HTTP 422 with an `ErrorResult` body for `ValidationError` — same `VALIDATION_ERROR` code and `invalidProperty`/`invalidValue` detail keys as `RestApiExceptionHandler.handleValidationError`. Every other outcome (success, 403/404/409/500) is byte-for-byte unchanged: still a real HTTP 200 carrying an `ActionExecutionResponse` with those pseudo-status codes embedded in the body.

This is a deliberate breaking change to those two endpoints' error contract — approved explicitly rather than shipped as a side effect. Concretely: code awaiting `client.actions.execute(...)` now has that call throw `DynamiaApiError` on a validation failure instead of resolving with `response.statusCode === 406`.

No SDK/frontend code changes were needed: `HttpClient.request` already throws `DynamiaApiError` uniformly for any non-2xx response regardless of body shape (this is exactly how `client.crud(path).create()` already surfaced its own 422s), and `useCrudPage.ts`'s save/delete handlers already catch generically. Added unit tests covering success/validation-error/not-found paths in `ApplicationMetadataControllerTest`.

Pending: PR against `main`.