[P3] objectui `ActionRunner`: the `execute || target` fallback is dead code since #3742 — confirm and delete

[os-zhuang]

Filed per Prime Directive #10. The work lands in the sibling repo objectui, so it is tracked here rather than folded into a framework PR.

Background

#3713 recorded that three readers resolved "the author declared both target and execute" in two opposite directions, and objectui's ActionRunner was one of them — it did execute || target, preferring the deprecated alias, while the spec transform preferred target. An action declaring both ran one script server-side and a different one client-side.

#3742 fixed this by construction rather than by patching each reader: the ActionSchema transform now drops execute from the parsed output entirely. Its changeset called this out explicitly —

It also fixes unpatched renderers by construction: an execute || target reader falls through to target once the alias is gone.

— and noted the objectui counterpart ships separately.

The claim to verify

Because execute no longer exists on parsed metadata, execute || target in ActionRunner can only ever evaluate to target. The fallback is unreachable. It is harmless today, but it is exactly the kind of residue that reads as a live contract to the next person: someone maintaining ActionRunner sees two slots, assumes both are real, and re-introduces a dialect (Prime Directive #12 — "a tolerant fallback fossilizes the wrong convention into a second de-facto contract").

z.infer<typeof ActionSchema> no longer carries execute, so a TypeScript reader in objectui should already fail to compile against a current spec — which is worth checking, because if it still compiles, something in objectui is reading a looser type than the spec's.

Suggested shape

1. In objectui, locate every execute read on action metadata (ActionRunner.executeScript and any sibling — the dashboard/page action paths are worth grepping too, not just the one named in [P2] action execute vs target: spec and objectui resolve the precedence in OPPOSITE directions #3713).
2. Confirm each is unreachable against the current spec type, then delete the fallback so the renderer reads target only.
3. If any of them still typechecks, that is the real finding — it means the reader is typed against something other than z.infer<typeof ActionSchema>, and the type, not the fallback, is the bug.

Refs #3713, #3742, #3743, #3838.