Stop claiming a terminal, and stop calling a recoverable delete final

Two bugs Bryan hit, with one shape between them: a claim stronger than
the thing that was measured.

**The delete warning branched on `imported`.** It told him deleting
`ai-app` could be undone and deleting `manager` could not, when both are
claude-cli sessions whose conversations survive equally. `imported`
records how a session got into the app; what decides recoverability is
whether the *driver* keeps its own record -- the Claude Code CLI does,
under ~/.claude/projects, however the session started; echo and llama.cpp
do not, and for those the app's transcript is the only copy. So the fact
now sits on DriverKind and rides on SessionInfo, decided by the server
from the provider's kind rather than by the phone from its name, which a
person can change.

The comment above the branch asserted "a session started here has no copy
anywhere". That sentence was the bug written down and reasoned from, and
it is gone.

Neither branch promises a restore, which it should not: nothing here
checks the file is still on disk, and re-importing was never a restore
anyway -- this app's transcript holds images, peer messages and command
events the CLI's record never had. So the recoverable text says what is
known and names what goes either way. "Can't be undone" is now said only
where it is true, which is the point of saying it at all.

**"open in a terminal -- close it there first" named a place that need
not exist.** The detection is right and worth keeping: something live
holds that session, and importing it would reproduce the double-resume
incident. But which something was never measured. The live descriptors
here include two of this backend's own adopted sessions and a peer
agent's; none is a terminal, so the instruction sent the reader looking
for a window that was not there.

**And this app did not recognise its own spawned sessions.** The import
list filters out what the app is already driving, but it matched only the
import cursor -- which exists solely for imported sessions. Every session
the app spawned therefore stayed in the list, marked in use, telling the
reader to go and close it somewhere: here. Matching the resume token too,
which both kinds have, is the fix; `session_importing` is now
`session_driving`, because that is what it was always being asked.

Verified on the emulator against a scratch backend: a spawned claude-cli
session reports keepsOwnTranscript true with imported false -- Bryan's
`manager` case exactly -- and draws the recoverable warning; the echo
session draws "can't be undone"; and once the CLI named itself, the
spawned session's id was absent from the import list, where the old match
would have listed it.

75 tests, clippy and rustfmt clean; ktfmt, compileDebugKotlin and
lintDebug clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VETa8afmpWaYezLCqJhDB8

server/src/routes.rs

@@ -431,7 +431,7 @@ async fn list_importable(
     // Joined here because the importer knows about files and the manager
     // knows about sessions, and putting the two together is the route's
     // job rather than either one's.
-    found.retain(|candidate| manager.session_importing(&candidate.id).is_none());
+    found.retain(|candidate| manager.session_driving(&candidate.id).is_none());
     Ok(axum::Json(found))
 }
 
@@ -477,7 +477,7 @@ async fn spawn_session(
                         body.setup
                     ))
                 })?;
-            if let Some(existing) = manager.session_importing(want) {
+            if let Some(existing) = manager.session_driving(want) {
                 return Err(ApiError::BadRequest(format!(
                     "session {existing} is already continuing that one -- delete it first if you \
                      want a fresh copy. Deleting it here does not touch the conversation itself, \