feat: show a quit prompt on first Ctrl-C in native TUI

[sadjow]

Summary

This PR changes the interactive native TUI so the first Ctrl-C does not immediately quit devenv.

Instead:

• the first Ctrl-C opens a quit prompt
• managed processes keep running after that first Ctrl-C
• c or Esc keeps running and clears the prompt
• q or a second Ctrl-C quits devenv

Motivation

Today, a single Ctrl-C immediately shuts down devenv and stops all managed processes.

This is easy to do by accident, especially while reading logs or working in a multi-process environment. When that happens, developers lose warm services and have to restart databases, app servers, and other managed processes unnecessarily.

This PR makes the first Ctrl-C non-terminal in the interactive TUI flow so users can decide whether to keep working or quit, without interrupting managed processes on that first press.

Behavior

Previous behavior:

• first Ctrl-C shut down devenv
• managed processes were stopped as part of manager shutdown

New TUI behavior:

• first Ctrl-C opens a quit prompt
• managed processes continue running
• c or Esc keeps running and clears the prompt
• q or Ctrl-C quits devenv using the existing shutdown path

Expanded logs keep their existing selection-copy behavior:

• Ctrl-C still copies selected text
• when there is no active selection, the quit prompt flow above applies

Scope

• interactive TUI path with the native process manager only
• non-TUI foreground behavior is unchanged
• the first Ctrl-C does not send any signal to managed processes

Implementation notes

• reuses the TUI interrupt prompt state without forwarding the first Ctrl-C to the process manager
• keeps quit handling on q or a second Ctrl-C
• removes the earlier broadcast-interrupt manager command from this draft
• renders the prompt in both the main view and expanded logs view

Testing

• cargo test -p devenv-tui --quiet
• cargo test -p devenv-processes --lib --quiet
• docs and changelog updates

[sadjow]

Potential follow-up after this lands: the first Ctrl-C prompt could grow additional actions beyond c/q, for example lightweight process info, diagnostics, or selected-process controls. I think it makes sense to keep this PR scoped to the prompt-only behavior and revisit those extra options separately once the base interaction settles.

[sadjow]

This branch includes a few intermediate iterations while I refined the behavior, so squash-and-merge would probably be the cleanest merge strategy if the PR is accepted.

[domenkozar]

What's the motivation for prompting after ctrl-c?

[sadjow]

What's the motivation for prompting after ctrl-c?

@domenkozar accidental quit, especially because Ctrl-c is also a shortcut to copy on Linux and Windows. It's also an inspiration from Phoenix Framework; see this when typing ctrl+c

I'm also missing this feature from the previous default process manager: process compose that also prompts about exiting.

[sadjow]

@domenkozar, please let me know any thoughts. I can adjust. Is there an open channel to talk about features? Discord, etcc? Asking that because I have a couple of other ideas. But, I think this channel here is good as well.