Action Flows: generic CrudState enforcement for any CrudRemoteAction

[marioserrano09]

Summary

Part of #79.

CrudState (the entity's CREATE/UPDATE/READ/... lifecycle state) is only enforced server-side inside SaveSupport.persist for SaveRemoteAction/SaveFlowRemoteAction. It is not enforced generically in ApplicationMetadataController.executeAction(...) for any CrudRemoteAction.

Problem

A hand-crafted request against a CrudRemoteAction that doesn't go through SaveSupport (any future action beyond the two shipped in Phase 4) can still invoke server-side mutation logic while the action's declared applicableStates says it shouldn't apply — the original latent bug (§7.6 point 2) is only partially fixed.

Proposed work

• Add a cheap, generic CrudRemoteAction.getApplicableStates() check in ApplicationMetadataController.executeAction(...) (or a shared dispatch helper), so every current and future CrudRemoteAction gets this for free instead of each implementation having to remember to check it itself.
• Add a regression test that a request against a declared-inapplicable state is rejected before the action's execute()/start() runs.

References

• platform/core/crud/.../actions/remote/SaveSupport.java
• ApplicationMetadataController.executeAction
• docs/design/SERVER_DRIVEN_ACTION_FLOWS.md §7.6 point 2

[marioserrano09]

Implemented on `feature/action-flows` (commit 52babb9, plus two drive-by JUnit4→5 import fixes needed to get the reactor building green again: d5dd827, df5eddf).

`ApplicationMetadataController.executeAction` now rejects any `CrudRemoteAction` request whose inferred `CrudState` isn't in `getApplicableStates()`, before `execute()`/`start()` runs — generic, not scoped to `SaveSupport` only. Inference: entity id present (`dataId`/`data.id`/non-empty `data.ids`/raw list body) → existing entity, must declare READ/UPDATE/DELETE; no id → new entity, must declare CREATE. 11 new unit tests in `ApplicationMetadataControllerTest` cover the matrix, including bulk-delete's `ids` map and raw-list-body shapes.

Known limit, by design (documented in the commit and in §7.6 point 2 of the design doc): this only distinguishes "existing" vs "new" — it can't tell READ from UPDATE from DELETE for an existing entity from the request alone, since CrudState here represents the client's current UI view-state, not something derivable from the wire payload. Actions needing that finer distinction (like SaveRemoteAction CREATE-vs-UPDATE) still enforce it themselves.

Pending: PR against main.