feat(cli): make -S/--session resume-or-create with caller-chosen session names

Summary

kimi -S <id> / --resume <id> currently hard-errors when the given session does not exist (Session "<id>" not found.). This proposal: make -S <name> a resume-or-create operation — resume the session if it exists, otherwise create a new session with that caller-chosen identifier.

Use case

Scripted and recurring workflows need stable, meaningful session handles. Today the only way to re-enter a specific session is to first discover its generated session_<uuid> ID (via /sessions, kimi -S with no value, or digging through ~/.kimi-code/sessions/), store it somewhere, and pass it back later. That makes automation awkward:

# What I want:
kimi -S nightly-audit        # first run: creates the session
kimi -S nightly-audit        # every later run: resumes it

# What I have to do today:
kimi                          # create a session, remember its uuid somehow
kimi -S session_3f9a...       # resume by opaque uuid

Named sessions also make /sessions picker entries self-describing and let exit hints (To resume this session: kimi -r <id>) print something a human can actually remember and retype.

Current behavior

• Interactive startup with -S <id>: lookup via listSessions({ sessionId }); on miss, throws Session "<id>" not found. (apps/kimi-code/src/tui/kimi-tui.ts, in KimiTUI.init()).
• Print mode (kimi -p -S <id>): same lookup, same error (apps/kimi-code/src/cli/run-prompt.ts).
• All session identifiers are generated: session_${randomUUID()} in both engines (createSessionId in packages/agent-core and packages/agent-core-v2).
• The title field (/title, /rename) is display-only; nothing resolves sessions by it.

Why this fits existing semantics

The resume-or-create pattern already exists in the codebase. --continue does exactly this for the implicit "latest session in cwd" target: in KimiTUI.init(), if no session exists for the working directory it silently creates a fresh one with the notice No sessions to continue under "<dir>"; starting a fresh session. This proposal generalizes that accepted fall-through from an implicit target to an explicit identifier.

The plumbing for caller-chosen IDs already exists. CreateSessionOptions.id?: string (packages/node-sdk/src/types.ts) is threaded through both engines — v1 uses options.id ?? createSessionId(), v2 uses opts.sessionId ?? createSessionId(). The CLI simply never passes a value. So this is mostly a CLI-surface change, not an engine change.

Proposed behavior

1. kimi -S <name>: if a session with that ID exists, resume it (unchanged). If not, create a new session with id: <name> instead of erroring — presumably with a startup notice like No session "<name>" found; created it.
2. The created session's title could default to the name, so it shows up readably in the /sessions picker.
3. Same behavior in print mode (kimi -p -S <name>).

Implementation notes / things to decide

From reading the code, a few points a maintainer decision would need to cover:

• ID charset validation in v2. v1 enforces isSafeSessionId (/^[A-Za-z0-9._-]+$/, rejecting ./..) on every create/fork/path-resolution path. v2 declares SESSION_ID_INVALID but never throws it — sessionDirOf is a bare join(homeDir, handlerScope, sessionId), so an arbitrary caller-supplied ID containing / or .. would be a path-traversal hole on the delete path. This feature must port the v1 validation into v2 before accepting user-supplied IDs. The v1 charset is also URL-safe, which matters for kap-server routes and the /sessions/<id> web deep-link.
• Global namespace. The session index is global across working directories, so names would be globally unique, not per-project. Worth documenting, or alternatively scoping named sessions per workDir.
• Collision policy. If <name> already exists as a session created under a different directory, the existing same-directory guard presumably still applies (error with the cd "<workDir>" && kimi -r <id> hint) rather than silently resuming the wrong project.
• Docs. The CLI reference and data-locations docs would need updating; both locales.

Offer to implement

Per CONTRIBUTING.md I understand external feature PRs are by invitation. If the team agrees with the direction, I'd be happy to implement it (with tests, changeset, and docs) under maintainer guidance — or leave it to the team, whichever you prefer.

Start with KimiTUI.init() in apps/kimi-code/src/tui/kimi-tui.ts and the corresponding lookup in apps/kimi-code/src/cli/run-prompt.ts, then inspect CreateSessionOptions in packages/node-sdk/src/types.ts and both agent-core engines. Check the existing v1 session-ID validation before considering v2, and review the CLI reference and data-locations docs. Done means named IDs resume or create consistently in interactive and print modes, with tests, validation, and documentation covering the agreed collision behavior.