fix: run Herdr pane payload under bash so non-bash shells work - #594

`herdr pane run` injects its command string into the pane's *interactive*
shell, which is not necessarily bash. The completion sentinel was written
in bash syntax, so under fish the pane shell fails to parse it and tuicr
never starts:

  - `$?` is not fish's exit-status variable (it is `$status`), and fish
    rejects it at parse time
  - `tuicr_status=$?` is not valid fish; assignment is `set tuicr_status ...`

Wrap the payload in `bash -c '...'` so the pane's shell only has to forward
a single-quoted argument. Single-quote semantics are identical in bash, zsh
and fish, so all three hand bash a byte-identical string.

This also fixes a latent bug on the same line: $quoted_tuicr is built with
bash's `printf %q`, which emits `$'...'` ANSI-C quoting for awkward paths.
That was previously being parsed by the pane's shell, which may have no such
syntax; it is now read by bash, which produced it.

`bash -c` rather than `sh -c` for that same reason -- `$'...'` is not POSIX,
so dash would choke on it. The payload itself is otherwise POSIX-clean.

Verified on macOS with fish as the pane shell: the pane splits, tuicr runs,
the completion token is matched by `wait-output`, and the wrapper exits with
tuicr's own status. Payload output is byte-identical under bash, zsh and fish.