Advertise the instance from enableRemote and report attention status on the heartbeat

[iscekic]

Two CLI-side fixes for defects found by an end-to-end verification run of the Kilo mobile app, each confirmed by an independent code triage before any code was written.

/remote never registered the CLI as a spawn target

Enabling the remote relay from the TUI /remote slash command connected the socket and mirrored sessions correctly, but the CLI never appeared in the mobile app's "Run on" picker. Only the explicit kilo remote command called setInstanceAdvertisement, so getConnectedInstances() filtered the socket out on the cloud side.

The advertisement now runs on every successful enableRemote() entry. The placement matters more than it looks: enableRemote() opens with if (remote) return, and bootstrap auto-enable frequently connects first, so /remote usually hits that early return — an advertisement placed in the connection-setup body would have left the defect unfixed in the common case. ingestDisabled returns before the advertisement and stays unadvertised.

The ensure helper no-ops when an advertisement is already set, so it fires no extra heartbeat, while explicit setInstanceAdvertisement keeps its existing replace semantics and tests. buildInstanceAdvertisement moved to a shared module so both entry points derive it identically.

A session blocked on a question reported as busy

The heartbeat built each session's status from SessionStatus.Service — union idle|retry|busy|offline — which never consults Question.Service or Permission.Service. deriveStatus() already did consult both, but only fed the ingest session_status sync. So a session genuinely blocked on a question was advertised as busy, and the mobile app, which takes live row status from the heartbeat, showed no needs-input badge.

The precedence (permission, then question, then SessionStatus) is now a shared helper used by both deriveStatus and the heartbeat, so the two channels cannot drift.

The heartbeat runs on a ~10s timer across every session and deriveStatus makes service calls per session, so the permission and question lists are fetched once per tick and indexed by session id rather than queried per session. A test pins the call count.

Behaviour note

Sharing the derivation also means a SessionStatus of offline now reports as retry on the wire, matching what deriveStatus has always sent to ingest. Nothing consumes offline from the heartbeat — the transport forwards only idle and busy, and the mobile row treats both as non-attention — so the practical effect is that the two channels now agree. The detach fence test is parameterised accordingly; its assertion that the status clears on detach is unchanged.

Relationship to the cloud change

Kilo-Org/cloud#4769 fixes the same needs-input defect from the other side, by overlaying the stored status onto live rows. That change covers already-released CLIs and does not depend on this one; this change fixes it at the source so the two status channels agree. Neither PR blocks the other.

Checks

packages/opencode typecheck and the affected suites pass (21 tests including the DEF-1 contract cases and the DEF-3 batching call-count assertion). Independent reviewer over the full diff: no findings.

[iscekic]

(bot) Device E2E complete on e76b352689. Both CLI-side fixes verified against a local stack, using a build of this branch (0.0.0-fix-cli-remote-advertise-and-attention-status-…) alongside the stock released 7.4.16 as a control.

DEF-1 — /remote registers the CLI as a spawn target: PASS. With remote enabled from the TUI slash command, the instance appears in the mobile app's "Run on" picker, and a session started from the app reaches the CLI and returns a real response. The control confirms the change is what did it: the stock CLI, with /remote enabled the same way and its sessions mirroring correctly, does not appear in the picker.

DEF-3 — heartbeat reports pending attention: PASS.

Sample	Live status on the raw worker endpoint
Patched, question pending, +31s	question
Patched, +12s later	question (stable)
Patched, after answering	leaves question → idle
Stock 7.4.16, question pending, 3 samples over ~25s	busy, busy, busy

One correction to an earlier interim result. A first E2E pass reported this as "not proven" because the live endpoint still showed busy. That was a sampling race, not a defect: the DB flips within milliseconds of the question being raised, but the heartbeat only fires every ~10s, so a request issued immediately after can still return the previous heartbeat. Re-sampled after a full heartbeat period, the patched build reports question correctly. No code change was needed, and none was made — the investigation is recorded here because "we changed nothing and it now passes" deserves the evidence.

The stock column is also why Kilo-Org/cloud#4769 exists: released CLIs will never report attention on the heartbeat, so the cloud side overlays the stored status. That PR is independent of this one and needs no coordination to land.