fix: prevent session loss and repair launch lifecycle races

[1jehuang]

Summary

• wait briefly for a newly launched daemon to register before SDK close() gives up
• cover delayed servers.json publication with a regression test
• update the Claude memory sidecar to the valid Haiku 4.5 model ID
• refuse destructive empty transcript checkpoints and preserve byte-identical pre-wipe recovery copies
• detect immediate non-zero terminal spawn-hook exits so visible/auto swarm spawns fall back instead of remaining startup queued

Fixes #818.
Fixes #798.
Fixes #814.
Fixes #792.

Verification

• npm test -- --test-name-pattern="daemon shutdown lookup|cleanup refuses|removing an instance"
• cargo test -p jcode-base --lib sidecar::
• cargo test -p jcode-base session::persistence::tests --lib (3 passed)
• cargo test -p jcode-base terminal_launch::tests --lib
• cargo test -p jcode-app-core server::comm_session_tests::prepare_visible_spawn_session --lib
• 8 concurrent SDK launch/close lifecycle trials, 0 leaked daemon registrations
• git diff --check
• cargo fmt --all -- --check

--- — Jcode agent (automated triage), on behalf of @1jehuang

[1jehuang]

CI follow-through found and repaired three unrelated guardrail regressions already present on the base branch: a collapsible conditional, a dead auth helper, and a contradictory strict-schema fixture. The focused suites now pass locally. The repository-wide guardrail is still blocked by two additional pre-existing Rust 1.97 clippy findings in jcode-app-core (needless_return and too_many_arguments), so I am leaving this PR unmerged rather than expanding an issue-specific fix into a broad cleanup.

--- — Jcode agent (automated triage), on behalf of @1jehuang

[1jehuang]

Final CI follow-through: the issue-specific SDK and sidecar checks continue to pass, and the bounded Rust 1.97 findings fixed on this branch are resolved. The repository-wide guardrail now advances into jcode-tui and reports 14 additional base-branch dead-code/cfg lint failures across onboarding and terminal notifications. That is a broad, unrelated cleanup boundary, so this PR remains open and unmerged rather than masking or absorbing those changes.

--- — Jcode agent (automated triage), on behalf of @1jehuang

[1jehuang]

Runtime acceptance check for #818 passed: a selfdev build of this branch completed, then 8 concurrent public SDK launch() → immediate close() trials completed with 0 leaked daemon processes. This exercises the SDK, bridge, daemon registration, shutdown, process-group signaling, and ephemeral cleanup boundary end to end.

--- — Jcode agent (automated triage), on behalf of @1jehuang

[greptile-apps]

Greptile Summary

This change updates daemon shutdown polling, terminal spawn-hook handling, scheduled-turn rendering, transcript checkpoint safeguards, sidecar model selection, and related tests and release metadata.

A focused persisted-session test reproduced a role-boundary failure: an ordinary user message beginning with [Scheduled task]\n is rendered as a system message and excluded from visible-conversation accounting after reload.

T-Rex validation blocked

The executed reproduction artifacts could not be uploaded because the required Greptile artifact-upload tool was unavailable. The saved local test source and output cannot be presented as uploaded evidence.

Confidence Score: 4/5

Security Review

User-controlled message text can select the legacy scheduled-task classifier. A persisted Role::User message with no display-role override is promoted to system presentation and hidden from visible-conversation accounting when its text starts with [Scheduled task] . This breaks the boundary between user-authored content and reserved system-role content; classification must use trusted scheduler provenance rather than a forgeable prefix.

T-Rex Logs

What T-Rex did

• T-Rex produced a proof for the posted P1 finding.
• T-Rex verified contract-validation evidence by confirming the executed source and command captures are stored in the trex-artifacts bundle and that there is no Greptile artifact upload mechanism in the available tool set.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   User-controlled scheduled-task prefix reclassifies a persisted user message as system

   • Bug
     • A persisted Role::User message with display_role: None and text beginning [Scheduled task] is rendered with the system role and excluded from visible-conversation accounting after serialization and reload.
   • Cause
     • is_scheduled_task_message trusts a user-controlled text prefix; both the renderer and visible-conversation filter consume that classifier.
   • Fix
     • Require a trusted persisted scheduler provenance marker or explicit scheduler-owned display role; do not infer elevated presentation role from ordinary user-controlled text.

   _{Ran code and verified through T-Rex}

Prompt To Fix All With AI

### Issue 1
crates/jcode-base/src/session/render.rs:415
**User messages gain system role**

An ordinary persisted `Role::User` message with no explicit display role can begin with `[Scheduled task]\n` and match the legacy scheduled-task classifier. This branch then renders user-controlled content with the `system` role; the same classifier also removes it from visible-conversation accounting. Determine scheduled-task status from trusted scheduler provenance or an explicit persisted marker, not user-controlled text.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (7): Last reviewed commit: "chore(release): prepare v0.71.0" | Re-trigger Greptile}

[1jehuang]

Acceptance follow-up:

• Data-loss: session close path can wipe a large transcript (fix + tests available on fork) #814: packaged-binary, isolated-daemon close/resume passed. A marker written before close was returned exactly after resume.
• Feature request: native tmux pane spawning for swarm teammates (same-window multi-agent view, like Claude Code) #792: focused hook and visible-session lifecycle tests pass. A packaged-binary acceptance attempt reached the swarm public interface, but standalone jcode run sessions cannot initialize swarm membership (Not in a swarm), so a live tmux swarm result remains acceptance-blocked rather than claimed as passed.
• The full TUI package compiled and its public version and --help entry points passed.

--- — Jcode agent (automated triage), on behalf of @1jehuang

[greptile-apps]

User messages gain system role

An ordinary persisted Role::User message with no explicit display role can begin with [Scheduled task]\n and match the legacy scheduled-task classifier. This branch then renders user-controlled content with the system role; the same classifier also removes it from visible-conversation accounting. Determine scheduled-task status from trusted scheduler provenance or an explicit persisted marker, not user-controlled text.

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/jcode-base/src/session/render.rs
Line: 415

Comment:
**User messages gain system role**

An ordinary persisted `Role::User` message with no explicit display role can begin with `[Scheduled task]\n` and match the legacy scheduled-task classifier. This branch then renders user-controlled content with the `system` role; the same classifier also removes it from visible-conversation accounting. Determine scheduled-task status from trusted scheduler provenance or an explicit persisted marker, not user-controlled text.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.