fix/feat: Issue 454 and 607, self_termination_guardrail

[collin-kierce]

This PR aims to address issues #454 and #607.
It refactors existing shell-command guards into a shared framework and adds a mandatory, defense-in-depth detector for direct process-termination commands targeting the active Code Puppy process or selected ancestors.

This is not complete protection against same-user arbitrary code execution. Interpreter indirection, external shell-like tools, delayed/background execution, and OS-level isolation remain follow-up work.

Changes

1. Extract shared guard callback plumbing

Adds code_puppy/plugins/guard_framework.py, which centralizes the common callback flow used by:

• destructive_command_guard
• force_push_guard
• the new self_termination_guardrail

The shared framework handles disabled-guard policy, interactive approval prompts, non-interactive blocking, and consistent blocked-command responses. The self-termination guard opts out of the normal dangerous-command disable setting.

2. Add self_termination_guardrail

Adds a guard intended to block direct shell commands that could terminate Code Puppy or selected parent processes. At plugin initialization, the detector walks the current process’s parent chain and builds a protected identifier set from process names and PIDs, along with static Code Puppy and shell aliases.

Before a shell command is run, the detector:

• identifies the executable and arguments, including several common command wrappers;
• checks whether the executable is a recognized process-termination utility, such as kill, pkill, killall, taskkill, Stop-Process, or spps;
• checks whether an argument targets a protected identifier.

When both conditions match, the command is blocked immediately without a user-approval prompt or the normal dangerous-command guard bypass.