spawn: hermes has no CLI mode to start interactive with a seeded initial prompt

[fujibee]

Problem

spawn.sh fails for hermes with an argparse "invalid choice" error: cli=hermes + a bare positional prompt doesn't work, because hermes's CLI requires a subcommand (chat, model, ...) as its first positional argument — there is no free-text top-level positional.

Found while smoke-testing all 9 spawnable types after #278 (which fixed the same general class of problem for antigravity/copilot/opencode/cursor/gemini). hermes was already marked spawnable=yes before #278 — this is a pre-existing bug, not a regression from that PR.

Why #278's fixes don't apply here

#278 added two mechanisms:

1. prompt_arg=<flag> — for a CLI whose prompt is the value of a named flag (antigravity's --prompt-interactive, copilot's --interactive).
2. a relaxed cli= (fixed multi-word prefix, e.g. opencode's cli=opencode run --interactive) — for a CLI that needs a subcommand plus a plain boolean flag to stay interactive.

Neither fits hermes. Checked hermes --help and hermes chat --help directly:

• -z PROMPT, --oneshot PROMPT (top-level): "One-shot mode: send a single prompt and print ONLY the final response text to stdout." — non-interactive, exits after one turn.
• hermes chat -q QUERY, --query QUERY: "Single query (non-interactive mode)" — also exits after one turn.
• hermes chat has no positional argument at all, and no other flag that starts an interactive session pre-seeded with an initial message.

So there is currently no known hermes CLI invocation that does what spawn.sh needs: start an interactive session AND have it act on the actas prompt as its first turn.

Possible directions (not investigated in depth)

• A two-step boot: hermes chat -q "<prompt>" --continue (or similar) launched in sequence from the boot script — hermes's -q one-shot session might be resumable via --continue/--resume, so the second launch could pick up where the first left off. This doesn't fit spawn.sh's current single-invocation boot-script model and needs testing to confirm hermes's session-continuation semantics actually work with no TTY between the two launches.
• Ask upstream (hermes CLI) whether a "start interactive with initial message" mode exists but is undocumented in --help.

Scope

Until one of the above is confirmed, hermes should probably be considered not actually spawn-capable despite its manifest saying spawnable=yes — worth flagging in the manifest/docs, or reverting spawnable=yes for it until a real fix lands, so spawn hermes fails with a clear message instead of an argparse error.