All three entry points that drop the user into a shell inside a sandbox
VM now share one launcher. Previously they each hardcoded a shell, with
two failure modes:

  - apps/runner/pkg/api/controllers/proxy.go:114 (dashboard / iframe
    terminal) hardcoded /bin/sh -- correct for the default alpine
    snapshot but no bash for users who'd prefer it.
  - apps/runner/pkg/sshgateway/service.go (public SSH gateway, fixed
    in baca7b6 to use StartExecution) defaulted /bin/bash -- broke
    on the default snapshot because bash is not installed.

Introduce apps/runner/pkg/shellutil/launcher.go with one helper:

    func DefaultInteractiveShell() (cmd string, args []string)

Returns: /bin/sh, ["-c", "exec $(command -v bash || command -v ash || command -v sh) -l"]

Rationale (kubectl exec convention, per Kubernetes docs):
  - /bin/sh is POSIX-required -> launcher process itself always starts.
  - command -v is POSIX, works on busybox/alpine and full distros.
  - exec replaces the launcher sh -> no extra PID; chosen shell is the
    session's pid 1.
  - -l makes it a login shell -> ~/.profile is sourced, PWD=$HOME,
    PATH/HOME exported. Matches what `ssh user@host` users expect.
  - Tries bash first (preferred), falls back to ash (alpine), then sh
    (POSIX guarantee).

Wired into:
  - apps/runner/pkg/api/controllers/proxy.go:handleWebSocketTerminal
  - apps/runner/pkg/sshgateway/service.go (default for `shell` requests;
    `exec` requests still take user-supplied commands as before)

The exec request path keeps /bin/sh -c <payload> unchanged: when the
user explicitly types `ssh host "cmd args"`, OpenSSH-canonical behaviour
is to run it under sh -c, and there is no shell-preference ambiguity to
resolve in that case.

OpenSSH 9.0+ scp defaults to the SFTP subsystem (RFC 4254 §6.5) instead
of the legacy `exec scp -t` protocol. Without "subsystem" handling, the
runner replies false and the client sees:

  subsystem request failed on channel 0
  scp: Connection closed

Add a case for "subsystem":
- only "sftp" is supported (matches the OpenSSH default)
- spawn sftp-server inside the VM via the same StartExecution path
- probe install locations in order (alpine /usr/lib/ssh, debian-ish
  /usr/lib/openssh, RHEL-ish /usr/libexec, plus PATH) so unusual
  layouts still work without per-image hardcoding
- no TTY for binary-protocol subsystems

Workaround if the VM ships no sftp-server: `scp -O -P 2222 ...` falls
back to the legacy protocol over `exec`, which has worked since the
baca7b6 rewrite.

Verified shell path still lands at boxlite:/# via the same SSH host.

Two launcher bugs surfaced by interactive testing:

1. Shell session landed at / instead of $HOME. OpenSSH-canonical
   behaviour is chdir(pw_dir) before exec'ing the user's shell -
   that's what makes `ssh user@host` drop you at ~. The -l flag
   sources profile but doesn't itself cd. Add `cd "${HOME:-/root}"`
   to the launcher so the SSH and dashboard-iframe terminal sessions
   both land at the user's home (mirrors what sshd does internally).

2. SFTP subsystem silently exited 0 when no sftp-server binary was
   found in the VM. `exec $(empty)` is a POSIX no-op that returns 0,
   so the scp client saw a clean EOF and reported only "Connection
   closed" with no error message. Move the launcher logic into
   shellutil.SftpSubsystem and explicitly check the resolved path:
   if empty, write a clear stderr message ("sftp-server not found in
   sandbox VM; install openssh-sftp-server, or fall back to 'scp -O'")
   and exit 127. The client now sees that message via the SSH stderr
   stream, and users can act on it.

Same shellutil helper covers both code paths (sshgateway + the
dashboard's WebSocket terminal), so behaviour stays consistent.