fix(cli): restore Pi session resume

[nannant666]

Summary

• pass Pi resume IDs with the supported --session <path|id> flag
• preserve the session Pi creates or resumes before entering RPC mode
• cover the child-process arguments and initial RPC sequence with a focused regression test

Why

HAPI currently starts resumed Pi sessions with pi --mode rpc --session-id <id>, but the official Pi CLI rejects --session-id and exposes --session <path|id>.

Pi also creates or loads its session before RPC mode starts. Sending new_session immediately afterward replaces the selected session and can race the following get_state, so HAPI may persist an ID for a session that will not receive subsequent prompts.

This change lets Pi own startup session initialization and only queries its initial state.

Testing

• bun typecheck
• cd cli && bunx vitest run src/pi/runPi.test.ts src/pi/session.test.ts (9 passed)
• bun run test:hub (643 passed, 3 skipped)
• cd web && bunx vitest run --maxWorkers=1 (1556 passed)
• bun run test:shared (142 passed)
• Pi 0.73.1 isolated manual check: --session-id exits with Unknown option; --session <id> returns the requested session ID and leaves the session file unchanged, without a model request

Local environment limits

The full CLI run completed 1518 tests with 5 unrelated host failures: four difftastic tests require glibc 2.32-2.34 while this host has 2.31, and the 20-process runner stress test exceeded the container 512-PID limit. The Pi tests pass independently.

[github-actions]

Findings
No findings.

Questions
None.

Summary
Review mode: initial
No high-confidence issues found in the latest diff. Residual risk: I did not run the PR code; coverage is focused on the resume startup path and does not add a separate fresh Pi launch regression test for the removed new_session RPC.

Testing
Not run (automation).

HAPI Bot

[github-actions]

Findings

• [Major] Keep fresh Pi launches on a new session — removing new_session here changes the non-resume path as well, so a plain pi launch can now pick up Pi's persisted session instead of starting a fresh conversation. The resume fix only needs to skip new_session when resumeSessionId is present. cli/src/pi/runPi.ts:391-394
  Suggested fix:

  if (!opts.resumeSessionId) {
      transport.send({ type: 'new_session' });
  }
  transport.send({ type: 'get_state' });

Summary

• Review mode: follow-up after new commits
• One major regression: the new startup path drops new_session for every Pi launch, not just resumed ones, so fresh launches may attach to the previous persisted session.
• Coverage gap: the added test only covers the resume branch; the non-resume startup path is still untested.

Testing

• Not run (automation)

HAPI Bot

[github-actions]

Findings

• No issues found in the latest diff.

Summary

• Review mode: follow-up after new commits
• The previous regression around fresh Pi launches was addressed in the current head: non-resume startup now omits only Pi-native resume args, resumed startup passes --session, and both paths avoid new_session before the initial get_state.
• Residual risk: I did not execute PR code; review is based on diff and surrounding source context only.

Testing

• Not run (automation; PR code execution disabled)

HAPI Bot