new_*_with_command keybind actions: one parameterized action or separate actions?

[jamesarch]

Context: I opened #12984 adding a new_tab_with_command:<cmd> keybind action (vouch request in #12977). @jcollie suggested discussing the broader design: should new windows and splits get the same capability, and should it be one parameterized action or separate actions?

Use case: dedicated shortcuts that open a surface running a specific command (e.g. ssh somehost), similar to iTerm2 profiles with commands.

Options I see:

1. Separate actions: new_tab_with_command:ssh host, new_window_with_command:ssh host, new_split_with_command:right,ssh host. Consistent with the existing new_tab / new_window / new_split:direction naming. Downside: three actions, and the split variant needs two parameters.
2. One parameterized action: e.g. new_surface_with_command:tab,ssh host. Fewer actions, but introduces a new syntax convention that doesn't match anything existing.
3. Extend existing actions with an optional argument: new_tab:ssh host, new_split:right,ssh host. No new actions at all, but changes the parsing and apprt plumbing of existing parameter-less actions, which touches every apprt.

My preference is option 1: it mirrors the existing action naming, is purely additive (no changes to existing action semantics or their C ABI types), and each action stays simple. My PR currently implements it scoped to tabs only; window/split variants could follow the same pattern in follow-ups. Happy to rework toward a different direction if maintainers prefer.

(Per AI_POLICY: drafted with Claude Code assistance, reviewed and edited by me.)