Successful /handoff creates a backend session but leaves the app on the old session

[devswha]

Reproduction

1. Open an app session in a disposable project.
2. Send and complete a normal message.
3. Run /handoff preserve HANDOFF_READY and accept the Run gate.

Observed

The builtin reports:

Handoff created; new session started with handoff context.

The backend project payload confirms a new GJC session row was created, but the browser remains on the old route, for example:

/session/2a100c62-7a09-4dca-a101-06377384a3b7

The sidebar is not refreshed to select the new session. In the test payload, the new backend session was 01a00bbf-4e81-7000-9679-f1013b4fa44b with title Untitled gjc Session.

Expected

A successful handoff should return the new session identity to the app, register/refresh it, and navigate to that session so the user can continue with the handoff context. If navigation is intentionally unsupported, the command must not claim that the app has started the new session without offering a way to open it.

Monitoring evidence

The backend remained healthy throughout the CUA run. /api/providers/sessions/running showed the old app session during command execution and returned to an empty running set after completion.

Environment

Gajae Code App v2.0.0-beta.3, macOS arm64, disposable local git project.

[devswha]

No heuristic app workaround was applied. The remaining fix requires the upstream handoff command to return a structured durable child-session identity. Once available, the app can emit a source/target transition event, refresh/register the child, and navigate only when the source session is active. Parsing the English success string or selecting the newest session remains explicitly rejected.