Spawns a new interactive PTY (pseudo-terminal) session that runs in the background.

Unlike the built-in bash tool which runs commands synchronously and waits for completion, PTY sessions persist and allow you to:
- Run long-running processes (dev servers, watch modes, etc.)
- Send interactive input (including Ctrl+C, arrow keys, etc.)
- Read output at any time
- Manage multiple concurrent terminal sessions

Usage:
- The `command` parameter is required (e.g., "npm", "python", "bash")
- Use `args` to pass arguments to the command (e.g., ["run", "dev"])
- Use `workdir` to set the working directory (defaults to project root)
- Use `env` to set additional environment variables
- Use `title` to give the session a human-readable name
- The `description` parameter is required: a clear, concise 5-10 word description
- Use `notifyOnExit` to receive a notification when the process exits (default: false)
- Use `timeoutSeconds` to auto-kill the PTY after a fixed number of seconds
- Do not set `timeoutSeconds` by default for sessions that are meant to keep running, such as dev servers, watch modes, local APIs, or REPLs. Only add a timeout for those when the user explicitly asks for one.
- Prefer setting `timeoutSeconds` for long-running commands that are still expected to finish on their own, such as builds, unit test suites, end-to-end tests, migrations, or other commands where you are waiting for a result.

Returns the session info including:
- `id`: Unique identifier (pty_XXXXXXXX) for use with other pty_* tools
- `pid`: Process ID
- `status`: Current status ("running")

After spawning, use:
- `pty_write` to send input to the PTY
- `pty_read` to read output from the PTY
- `pty_list` to see all active PTY sessions
- `pty_kill` to terminate the PTY

Exit Notifications:
When `notifyOnExit` is true, you will receive a message when the process exits containing:
- Session ID and title
- Exit code
- Total output lines
- Last line of output (truncated to 250 chars)

This is useful for long-running processes where you want to be notified when they complete
instead of polling with `pty_read`.
- Completion signal is the future `<pty_exited>` message
- If you only need to know whether the command finished, do not call `pty_read`; wait for `<pty_exited>`
- Never use sleep plus `pty_read` loops to check completion
- Use `pty_read` before exit only if you need live output now, the user explicitly asks for logs, or the exit notification reports a non-zero status and you need to investigate

Examples:
- Start a dev server: command="npm", args=["run", "dev"], title="Dev Server"
- Start a timed dev server when explicitly requested: command="npm", args=["run", "dev"], title="Dev Server", timeoutSeconds=600
- Start a Python REPL: command="python3", title="Python REPL"
- Run tests in watch mode: command="npm", args=["test", "--", "--watch"]
- Run build with notification and timeout: command="npm", args=["run", "build"], title="Build", notifyOnExit=true, timeoutSeconds=900
- Run end-to-end tests with timeout: command="npm", args=["run", "test:e2e"], title="E2E Tests", notifyOnExit=true, timeoutSeconds=1800
