Standalone authored action rows execute but are invisible to MCP list_actions/run_action (declaration-surfacing gap) #3010

Summary

The last residual from the #2605 "declared-but-not-wired" family, split out so the umbrella can close. This is a declaration-surfacing gap, not an execution gap: since #2608, a standalone authored action metadata row is registered into the engine by resyncAuthoredActions and its body executes via the REST /actions/... route — but the MCP action surface never sees it, because both MCP resolution paths read declarations exclusively from object.actions:

• listActions — packages/runtime/src/http-dispatcher.ts:813 iterates meta.listObjects() and collects obj.actions only.
• resolveActionByName (backing run_action) — packages/runtime/src/http-dispatcher.ts:1174 — same source.

So an AI agent calling list_actions will never discover a standalone authored action, and run_action on its name returns "Action not found", even when the row carries ai: { exposed: true }. Actions embedded in an authored object row are fine on both surfaces (they appear in obj.actions via the metadata service).

Scope notes

• Same declaration-surfacing family as the Studio-rail listing work (task_8dd7c8a0): the execution layer (engine registry via resyncAuthoredActions, packages/objectql/src/plugin.ts:1330) already merges standalone rows + object-embedded rows with artifact-wins semantics — only the declaration consumers (MCP bridge) don't.
• Any fix must preserve the MCP invoke-time gates as-is: ai.exposed fail-closed (Security: MCP action surface must gate on ai.exposed — action bodies run trusted (unbounded RLS/FLS), so invoke-time is the only agent boundary (#2849) #2849 / ADR-0011), the ADR-0066 D4 capability gate, and isHeadlessInvokableAction.
• Sketch: have the bridge's declaration source union meta.listObjects().actions with standalone action items (metadata.loadMany('action')), keyed the same way the engine registry keys them (object-scoped vs global), dedup artifact-wins — mirroring resyncAuthoredActionsNow's merge.

Origin

Noted as "Residual (not chased here)" in the #2605 wrap-up comment (#2605 (comment)); re-confirmed still present on main @ 93fd58e (2026-07-16).