Desktop-created cloud sessions never receive their kickoff prompt: `session.remote.notifySteerableChanged` unsupported by the native session bridge

## Summary

Every cloud session created **from the desktop app** is dead on arrival. The remote session is created successfully in the cloud, but the app can never mark it steerable, so the kickoff prompt is never delivered. The session then sits blank and idle forever, with no error surfaced anywhere the user can see it.

The cause is an RPC method the bridge doesn't implement — not a timeout that could be tuned away:

```
Request session.remote.notifySteerableChanged failed with message:
Direct native session bridge does not support session method 'session.remote.notifySteerableChanged'
```

## Environment

| Field | Value |
| --- | --- |
| App version | **1.1.8** (`0945da4`) and **1.1.9** (`07245f4`) — both affected |
| OS | macOS 26.6.1 (25G76), arm64 |
| Bundled CLI | 1.0.79-9 |
| Bundled gh / git | 2.96.0 / 2.53.0-4 |
| Repo | personal, public (`harshnag/multifoot`) |

## Repro

1. Create a cloud session with a kickoff prompt — either from the UI, or via the `create_session` tool with `execution_location: 'cloud'` and a `kickoff.prompt`.
2. The session appears in the sidebar.
3. Nothing ever happens in it. No output, no error, no spinner resolution.
4. Reopening or restarting the app does not help; the same failure repeats on every resume.

## Evidence

The app's own log names the failure *and* predicts its consequence:

```
2026-08-14T12:37:32.606550Z WARN github_app::session::core:
failed to mark resumed remote session steerable; sends may block
task_id=c4766aae-9a49-48f7-b348-03d4a86c22d1
error=RPC error -32603: Request session.remote.notifySteerableChanged failed with message:
Direct native session bridge does not support session method 'session.remote.notifySteerableChanged'
```

Full sequence for one session (`~/.copilot/logs/`):

```
12:06:46 github_app::handlers::workspace: cloud kickoff: creating session workspace_id=b96049e7-…
12:06:46 github_app::session::manager::lifecycle: creating new session execution_location=Cloud
12:06:59 [CLI] Created remote session in the cloud: c4766aae-9a49-48f7-b348-03d4a86c22d1
12:06:59 github_app::session::core: CLI session created create_session_rpc_ms=12065
12:07:00 github_app::handlers::workspace: cloud kickoff: session created workspace_id=b96049e7-…
12:09:00 ERROR github_app::handlers::session: failed to send message
error=operation timed out: cloud session was not steerable within 120s
12:09:01 ERROR frontend: [WebSocket] Server error: Failed to send message:
operation timed out: cloud session was not steerable within 120s
```

So the remote session exists — it just never gets told what to do.

On the CLI side, the same session logs the corresponding failure on every resume:

```
12:29:28 [WARNING] Failed to setup remote exporter for session c4766aae-…:
Error: Direct native session bridge does not support session method 'session.remote.notifySteerableChanged'
12:33:26 [WARNING] Failed to setup remote exporter for session c4766aae-… (same)
12:37:02 [WARNING] Failed to setup remote exporter for session c4766aae-… (same)
```

### Not a one-off

The oldest occurrence in my logs is **2026-08-13T19:15:54** against a different session (`e157aa75-2a9c-476e-ae2d-226dcd87fb57`) on 1.1.8. The most recent is **2026-08-14T12:37:32** on 1.1.9, after the update installed at 12:29. It reproduces on demand, across two app versions, for every cloud session I create.

### A separate, unrelated failure that cleared

Worth separating so it isn't mistaken for the cause. During the same window the Mission Control events endpoint was returning 503:

```
12:19:56 [WARNING] failed to list Mission Control task events
{"task_id":"c4766aae-…",
"url":"https://api.enterprise.githubcopilot.com/agents/tasks/c4766aae-…/events",
"status":503,"body_preview":"no healthy upstream"}
```

That endpoint responds normally now (400 missing-auth), githubstatus.com shows Copilot operational, and the steerability failure continues regardless. **The 503 was transient; the bridge gap is not.**

### The cloud agent backend itself is fine

Tasks started outside the desktop app run normally against the same repo and account — 46 `copilot/task-*` branches with commits landing today at 11:36, 12:13 and 12:22. This is specifically the desktop app's kickoff/steering path.

## Impact

Cloud sessions are the app's recommended way to hand work off to run unattended, and they're the only kind steerable later from GitHub Mobile. Right now, creating one from the desktop produces a session that looks created and does nothing — which is worse than a visible failure, because a user reasonably assumes it's working and comes back hours later to an empty session.

For my own project this is load-bearing: our `AGENTS.md` instructs each session to create its successor with `execution_location: 'cloud'` precisely so successors never share a local working tree. That instruction is currently unexecutable from the desktop app.

## Suggested fixes

1. **Implement `session.remote.notifySteerableChanged` on the direct native session bridge** (or route remote-exporter setup via a bridge that supports it).
2. Failing that, **don't gate the kickoff send on a steerability signal that can never arrive** — if the notify RPC is unsupported, fall back to polling readiness or send optimistically rather than blocking for 120s.
3. **Surface the failure in the UI.** `failed to mark resumed remote session steerable; sends may block` and `not steerable within 120s` both exist at WARN/ERROR in the log, and neither reaches the user. A session that will never respond should say so.

## Related, but not duplicates

- **#2383** — desktop can't *list or resume* cloud sessions started on github.com/mobile. That's about externally created sessions; these are created **by** the desktop and still fail.
- **#2110** — `session.remote.enable` failing on remote-control toggle. Different call, different path.
- **#1917** — "Failed to start cloud session". Mine *does* start (`Created remote session in the cloud`); it just never receives the prompt.
- **#111** (closed) — closest in shape: *"kickoff silently dropped, sessions become permanently dormant"* when a session-creation timeout was too short, for worktrees. Same symptom class, but that one was fixed by lengthening a timeout, which cannot help here — the method is absent, so no wait is long enough.

Happy to supply full logs if useful.

Start by tracing the desktop cloud-kickoff and resume paths through the direct native session bridge and remote-exporter setup, using the logged session.remote.notifySteerableChanged failure as the entry point. Verify the behavior with a newly created cloud session and its kickoff prompt. Done means the session becomes steerable and receives its prompt, or an unsupported bridge call produces a visible failure instead of a 120-second timeout.

索引モデルが issue の本文から書いたものです。