feat(tui): route shell and file tool approvals through typed execpolicy rules

[greyfreedom]

Summary

This PR wires the typed permission rules introduced in PR1 into the tool execution flow.

Shell and file-oriented tools now consult the ExecPolicyEngine before falling back to the existing approval behavior. This allows persistent rules such as:

• allow/deny/ask shell command prefixes via exec_shell
• allow/deny/ask file paths via read_file, write_file, edit_file, list_dir, and apply_patch
• compatibility aliases such as file_read, file_write, and file_edit

This does not add the approval-prompt persistence UI yet; that remains follow-up work.

Changes

• Add deepseek-execpolicy to the TUI crate.
• Load auto_allow, auto_deny, and [permissions.rules] from TUI config into an ExecPolicyEngine.
• Pass the configured policy engine into all engine entry points:
  • interactive TUI
  • deepseek -p
  • runtime threads
• Apply typed permission decisions during tool planning:
  • allow skips the existing approval prompt
  • ask forces the existing approval path
  • deny blocks execution before the tool runs
  • unmatched rules preserve existing behavior
• Support file path matching for:
  • workspace-relative paths
  • absolute paths under the workspace
  • symlink/canonicalized paths where applicable
• Apply permission checks to nested multi_tool_use.parallel calls so read-only file tools cannot bypass rules by being wrapped in a parallel call.
• Support project-level permission config only when it tightens policy:
  • project auto_deny is applied
  • project deny / ask rules are applied
  • project auto_allow and allow rules are ignored with warnings

Safety Notes

This PR keeps project-level permission config conservative. A repository-local config can require extra approval or deny access, but it cannot grant itself persistent allow rules.

For multi-path tools such as apply_patch, the implementation remains conservative:

• any matching deny blocks the call
• any matching ask requires approval
• allow is used only when every extracted path is covered
• partial matches fall back to the existing approval behavior

Tests

Validated with:

cargo fmt --all
cargo test -p deepseek-tui typed_permission
cargo test -p deepseek-tui project_overlay_applies_only_tightening_permission_rules
cargo clippy -p deepseek-tui -p deepseek-config --all-targets -- -D warnings
cargo test -p deepseek-tui
git diff --check

Depends On

This PR is stacked on top of PR1: feat/execpolicy-typed-rules
Part of #1186
Depends on #2046

[gemini-code-assist]

Code Review

This pull request implements a new typed permission system for shell and file tools, introducing the codewhale-execpolicy crate to manage layered rulesets and pattern matching. The system supports tool-specific decisions (allow, deny, ask) based on command prefixes and workspace-relative path globs, with integration across the TUI and app-server. Review feedback points out the use of the unstable let_chains feature in multiple files, which requires refactoring for stable Rust compatibility, and identifies a potential logic issue where legacy command rules might be duplicated during resolution.