[Fix]: Make PTY reader thread joinable so old-session output cannot bleed into the next tab

[matiaspalmac]

Description

spawn_pty started the reader thread with thread::spawn and threw away the JoinHandle. When PtyState was replaced (either via kill_pty or a second spawn_pty on the same slot), the old reader kept running on its cloned reader until it hit EOF. Any bytes the previous shell had already written to the PTY — including a prompt re-drawn by e.g. vim or less during teardown — then surfaced as pty-output events inside the new session's tab.

Related Issue

Fixes #79

Context / Problem

Minimal repro:

1. Open a terminal, run vim.
2. Kill the session (kill_pty — e.g. closing the terminal panel).
3. Immediately spawn a new one.
4. Observe leftover vim redraw bytes in the fresh tab.

Root cause: the old reader thread is still parked inside reader.read() when the new session starts. It eventually wakes up and calls app.emit("pty-output", ...), which the frontend routes to whichever terminal is currently open.

Change

• PtyState now owns an Arc<AtomicBool> shutdown flag and an Option<JoinHandle<()>>.
• The reader loop checks the flag between reads and bails before emitting if it is set, so bytes from a shell the user already killed can never reach a new session.
• New PtyState::shutdown_and_join(self) flips the flag, drops the master (closing the native handle — this is what actually unblocks the blocking read), then joins the thread.
• spawn_pty and kill_pty both take the old state out of the mutex first and only then run shutdown_and_join. Joining inside the lock would serialize teardown with every other PTY command and could deadlock on a reader re-entering via AppHandle::emit.

Trade-offs

• No Drop impl on PtyState. A Drop would run on &mut self, which cannot move master out before handle.join(). Joining with the master still alive deadlocks (the reader is parked inside read and only master closure wakes it up). Teardown is therefore a single explicit path (shutdown_and_join) that both callers always go through.
• No new unit tests. The fix is wiring that only manifests against a real PTY; the decoding logic already covered by [Fix]: Preserve UTF-8 codepoints across PTY 4 KiB read boundaries #173's test suite is unchanged here. Verified manually against the issue's repro on Windows.

Verification

• cargo check / cargo clippy --lib --no-deps -- -D warnings / cargo fmt --check clean.
• cargo test --lib → 30 passed (no regressions).
• Manual test: spawn → vim → kill_pty → spawn → no stray output.
• OS: Windows 11
• Version: v1.0.10

Checklist

• I have tested this fix thoroughly.
• I have followed the project's coding guidelines.
• My changes generate no new warnings or errors.
• I have verified the fix on:
  • OS: Windows
  • Version: v1.0.10

[github-actions]

Thanks for the contribution! I'll review it as soon as possible. If you have still changes, please mark this PR as draft and all reviews will be cancelled. Tests reviews will be re-run only when the PR is marked as ready for review.