docs(actions): document that body is script-only and how a modal target resolves

Keeps the two action docs in sync with the parse-time rule added in this PR
(and with the console-side target resolution in objectui#2826):

- ui/actions: a second "trap" callout next to the existing dead-button one —
  a `body` on a non-script action is rejected, with `type: 'script'` + `params`
  named as the shape for "collect input, then run logic".
- protocol/objectui/actions: `body` on a non-script type is now a parse-time
  error, not just "not meaningful"; the Modal Actions section states the
  page → object → server-handler resolution order and that `params` are
  collected before the target opens.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KYuc9N6YRbvoDMbCvJiX9f

Author: zhuangjianguo

content/docs/protocol/objectui/actions.mdx

@@ -55,7 +55,7 @@ The `type` field selects how an action is dispatched. The complete enum is **`sc
 
 ### Script Actions
 
-Run logic with no server round trip via `body` (an L1 CEL expression or L2 sandboxed JS). `body` is only meaningful when `type` is `script`.
+Run logic with no server round trip via `body` (an L1 CEL expression or L2 sandboxed JS). `body` is only meaningful when `type` is `script`, and declaring one on any other type is a parse-time error — those types dispatch on `target`, so the body would never be invoked.
 
 ```yaml
 name: greet_user
@@ -142,7 +142,7 @@ target: customer_quick_edit
 
 ### Modal Actions
 
-Open a modal/page by name:
+Open a modal/page by name. `target` is resolved as a **page** first, then as an object (which opens that object's create/edit form); when it names neither, the action falls through to its server-side handler.
 
 ```yaml
 name: edit_customer
@@ -151,6 +151,8 @@ type: modal
 target: customer_edit_modal
 ```
 
+A modal action may also declare `params` — the renderer collects them in a dialog before opening the target. It may **not** declare a `body`: see [Script Actions](#script-actions) above, and use `type: script` when the goal is to collect input and then run logic.
+
 ## Action Configuration
 
 ### Action Properties

content/docs/ui/actions.mdx

@@ -126,6 +126,17 @@ rejected at authoring time.) Also note the handler's `engine` facade is
 caller-specific rules yourself.
 </Callout>
 
+<Callout type="warn">
+**`body` belongs to `script` only.** Every other type dispatches on `target`
+— the page to open, the URL, the flow, the endpoint — so a `body` on a
+`modal`/`url`/`flow`/`api`/`form` action would never be invoked. Writing one
+(typically `type: 'modal'` with `params` and a `body`, expecting the body to
+run when the modal is submitted) is rejected at authoring time rather than
+shipping a button that opens a modal and silently writes nothing. To collect
+input *and* run logic, use `type: 'script'` with `params` — the same dialog
+is collected, then the body runs with those values as its `input`.
+</Callout>
+
 ## Bind it to the UI
 
 `locations` is the primary binding — the action appears wherever it declares: