[FEATURE] Render the session's statusLine in the Remote Control web/mobile UI

The web and mobile UI don't show the session's configured statusLine, so everything a user puts there is invisible the moment they pick up the phone.

Mine currently shows working directory, session cost, current model, and context window (percent remaining, an ASCII bar, and X/Y tokens). I want to add load average and battery, and here's the part that motivated filing: those live in my tmux status line today, which Remote Control also can't show me. So the natural move is to migrate them into the Claude statusline — except that's invisible remotely too. Both of the places a terminal user keeps ambient state disappear when you pick up the phone.

Slash commands aren't a substitute. statusLine output is arbitrary by design — that's the point of the feature. Working directory, git branch or worktree, hostname, load average, Kubernetes context, AWS profile, battery. No fixed set of built-in commands can cover it, because the content is user-defined.

It's worth more remotely than locally. At the terminal I know which machine and which directory a session is in — the window itself tells me. From the phone, sessions are a list of names, auto-generated from hostname or renamed by hand. When several concurrent sessions are running across more than one machine, the statusline is exactly the "which one is this" signal that's missing.

The value is already computed. Claude Code runs the statusLine command locally and has the rendered string. The docs describe the web and mobile interfaces as "a window into that local session." Forwarding that string and displaying it looks like transport and presentation rather than new capability.

One implementation note: statuslines commonly contain ANSI colour. Related observation from a Remote Control session — terminal-formatted output currently renders poorly on mobile, so this probably wants ANSI stripped or translated rather than passed through raw.

Prior requests, none of them triaged: #35483, #37317, and #40248 were all closed not planned after going stale. #55352 was then auto-closed by the dedup bot as a duplicate of #35483 — two weeks after #35483 had itself been closed — and is now locked, so it can't be reopened or commented on. Filing fresh because the bot's closing message says to do that when the dedup is wrong. #79155 (persistent context indicator, CLI-side) suggests the adjacent problem is live.

Related: #83424 (output from commands invoked on the phone never reaches the local session).