fix(server): /pty/stop returns 500 for PTY-only session ids (no backing session)

[0xabstracted]

Context

POST /sessions/:id/pty/stop (maestro-server sessionRoutes.ts) stops a server-hosted PTY. Its
body is:

ptyHostService.kill(id);
await sessionService.updateSession(id, { status: 'stopped' });
return res.json({ success: true });

Problem

Not every server-hosted PTY has a backing Session entity. The dev/test raw-shell path
(POST /dev/pty-test, and any PTY-only spawn) creates a PTY keyed by an id that is not a
persisted session. For such a PTY-only session id, kill(id) succeeds and tears the PTY down,
but the subsequent sessionService.updateSession(id, …) throws "session not found," the handler
falls into the catch, and the endpoint returns HTTP 500 pty_stop_failed — even though the
stop actually succeeded. The caller sees a failure for a successful operation, and the error
conflates "PTY kill failed" with "no session row to update."

Proposal

Make /pty/stop behave cleanly for PTY-only ids: the PTY is the thing being stopped; updating the
session row is a best-effort side effect. Kill the PTY first; only update the session when one
exists (or treat a missing session as a no-op, not an error). Return success when the PTY was
stopped; reserve non-2xx for an actual kill failure. Do not leak "session not found" as a
pty_stop_failed 500.

Acceptance criteria

• Stopping a PTY whose id has no backing session returns success (2xx), not 500, and the PTY is
  gone afterward.
• Stopping a normal session PTY still marks the session stopped as today.
• A genuine kill failure still surfaces as a non-2xx error, distinguishable from the
  missing-session case.
• Test coverage for both paths (session-backed id and PTY-only id).

Refs

Related to the hosted-terminal work (#140, #136). File:
maestro-server/src/api/sessionRoutes.ts (/sessions/:id/pty/stop, /dev/pty-test).