[Bug] Android sessions never get auto titles on 1.0.7+ hosts: legacy APK placeholder "Remote Code Session" is persisted as user-edited #3809

Summary

Sessions created from the published Android APK never get an automatic title: they stay named Remote Code Session forever. Host: OpenBitFun CLI 1.0.9 daemon (Linux x86_64). Client: OpenBitFun-Mobile-1.0.0-android-debug.apk (release mobile-v1.0.0, the latest Android build published).

Root cause (source-verified)

1. The mobile-v1.0.0 APK sends a literal placeholder when the user typed no title: SessionNaming.wireSessionName returns "Remote Code Session" / "Remote Cowork Session" / "Remote Assistant Session" (src/apps/mobile/shared/core-domain/.../SessionListPolicy.kt at tag mobile-v1.0.0).
2. Since v1.0.7 the host treats any non-empty session_name from remote_relay/bot as an explicit user title and persists {"titleSource":"text","titleUserEdited":true} (create_agent_session_from_runtime_request in coordinator.rs, still present on main).
3. update_session_title_if_current then returns early on titleUserEdited, so the first-turn auto title is never applied.

The client side was fixed in 6f931e4 (#3406, 2026-10-16: blank wire name, host picks the default), but no Android build containing it has been published, so every current Android user hits this with any 1.0.7+ host.

Evidence on my host

• Every session whose first turn id starts with mobile- has sessionName: "Remote Code Session", titleSource: "text", titleUserEdited: true; locally created sessions get generated titles normally (re-tested on 1.0.9: Session title updated: ... title=Reply With OK).
• Daemon log for the Android sessions: Skipped auto session title update because title changed. This wording is misleading: the same message is logged for the titleUserEdited early return, not only for a real title race.

Requests

1. Publish an Android build that includes 6f931e4, or
2. Host-side compatibility: treat exactly these three legacy placeholders from remote_relay/bot as the default-title path. I have a small patch with a unit test against v1.0.9 (built and tested locally) and can open a PR if that approach is acceptable.
3. Log a distinct message when the skip is caused by titleUserEdited.

Possibly related, not reproduced yet

In remote_surface/table.rs, update_session_title is CLI_NOT_IMPLEMENTED for the CLI peer host (only rename_session is handled), while the desktop LocalSessionDriver.renameSession invokes update_session_title. If the desktop uses that path when controlling a CLI peer host, rename would be refused. I could not capture the desktop request, so please treat this as a hypothesis.