flowHandler/serverActionHandler: toolbar launch with zero rows selected triggers a record-scoped run that crashes at its first record-bound node #2210

Repro (verified live on objectui main + framework showcase, 2026-07-04)

Showcase showcase_task list, action BulkReassignAction (type:'flow', target showcase_reassign_wizard, locations:['list_item','list_toolbar']):

1. Select no rows.
2. Click the toolbar "Reassign…" button → the FlowRunner screen ("New Assignee") opens anyway.
3. Fill a value, Submit → red error toast:

Node 'apply' failed: update_record(showcase_task) failed: Update requires an ID or options.multi=true

Root cause (code-verified)

packages/app-shell/src/hooks/useConsoleActionRuntime.tsx

• flowHandler (recordId fallback, ~L366-379): with no _rowRecord it falls back to context.selectedRecords; length === 1 resolves the id, length > 1 blocks with "select exactly one row" — but length === 0 falls through: recordId stays null/undefined and the trigger POST fires anyway. A record-scoped flow then pauses at its screen node, collects user input, and dies at the first record-bound node (update_record filter {id:'{recordId}'} → "Update requires an ID").
• serverActionHandler (~L434-442) has the identical zero-selection hole: resolvedRecordId stays null and the POST fires.

The row-level (list_item) invocation path works correctly (single green "Done" toast, record updated — verified live).

Expected

A record-scoped action launched from the toolbar with nothing selected should be blocked client-side with an actionable message ("select a row first"), the same way the multi-selection ambiguity already is — not silently trigger a run that collects wizard input and then crashes.

Record-scoped is knowable client-side: the action declares locations including list_item (it is designed to run on a row). Pure object-level toolbar actions (locations:['list_toolbar'] only, no record context needed) must keep working with no recordId.

Origin

Found during the showcase console dogfood audit (P0-27 in the capability report). The sibling symptom P0-35 (success + error double toast on row-level launch) is already fixed on current main — verified live.