Add sudo to forbidden commands and warn when running as root

[m-aebrer]

Summary

Two gaps in the forbidden-commands security layer around privilege escalation:

1. sudo is not blocked — agents will autonomously escalate privileges when normal access fails
2. No warning when dreb itself is running as root (making sudo unnecessary)

Observed Behavior

An agent was observed today escalating to sudo after a normal read returned empty (permission denied, silently swallowed by 2>/dev/null):

$ cat /etc/postgresql/14/main/pg_hba.conf 2>/dev/null | grep -v "^#" | grep -v "^$" | head -15
(no output)

$ sudo cat /etc/postgresql/14/main/pg_hba.conf 2>/dev/null | grep -v "^#" | grep -v "^$" | head -15
(no output)

$ sudo grep -v "^#" /etc/postgresql/14/main/pg_hba.conf | grep -v "^$"
sudo: a terminal is required to read the password
sudo: a password is required

The agent tried sudo twice before giving up. It only failed because the system required a password. On machines with NOPASSWD configured (common on dev machines, Docker, CI), this would have succeeded silently.

Proposed Changes

1. Add sudo to DEFAULT_FORBIDDEN_PATTERNS in packages/coding-agent/src/core/forbidden-commands.ts. Pattern: ^sudo\b — catches sudo at the start of any command segment. Also add to QUOTED_CONTENT_PATTERNS to block echo "sudo rm -rf /" | bash style evasion.

2. Add a startup warning when running as root — check process.getuid?.() === 0 early in startup and emit a visible TUI warning. Not a hard block (containers/CI may legitimately run as root), but a clear "you are giving the agent unrestricted root access" notice.

3. Add tests for both behaviors.

Why

• There is no legitimate reason for an AI agent to escalate privileges autonomously. It should work within the user's normal permission scope.
• NOPASSWD sudo is common in exactly the environments where dreb runs (dev machines, Docker, CI).
• The observed behavior proves agents will try sudo on their own initiative — this is autonomous privilege escalation and should be blocked at the guard level.

Acceptance Criteria

• sudo anything is blocked by the forbidden-commands guard (start of segment)
• cmd && sudo other is blocked (sudo after shell operator)
• echo "sudo rm -rf /" | bash is blocked (quoted content check)
• Running as root emits a visible warning in the TUI at startup
• Running as root does NOT hard-block execution
• Tests cover all of the above