[FEATURE]: Security Context-aware handling of sensitive files (credentials, tokens, secrets) Body: #26084

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

The AI currently reads and displays contents of sensitive files (e.g., .credentials, .env, .api.token, .account.secret, SSH keys) via read, cat, etc. This exposes secrets to the host/API, as seen in real sessions.

Core Principle

Distinguish between "using a path" and "exposing content":

• ✅ Allowed: Using file paths as references/arguments (e.g., mount -o credentials=/path/to/file, ls -la ~/.credentials)
• ❌ Forbidden: Reading/displaying file contents (cat, read tool output, showing content in messages)

Proposed Behavior

1. Sensitive File Detection

Detect files matching patterns: cred, secret, token, api, pass, .env, .pem, id_rsa, id_ed25519, key

2. Tool-Specific Rules

• Read Tool: Block displaying content of sensitive files. Allow path checks.
• Bash Tool: Allow commands using paths as arguments. Block cat, less, echo $(cat...) on sensitive files.
• Grep/Glob: Show that matches exist, but never display matching lines from sensitive files.

3. Explicit User Consent (Override)

If the user explicitly requests content access (e.g., "Show me my .env file"), the AI may proceed after:

• Displaying a clear warning: "Warning: This file contains secrets. The content will be visible. Proceed?"
• Getting explicit confirmation

4. Autonomy & Context

Empowered users can make informed decisions. The AI should:

• Not be overly restrictive when a path is just referenced
• Be strict when content would be leaked
• Trust explicit user consent with proper warnings

Goal

Improve security by preventing accidental secret leakage, while maintaining usefulness for system administration tasks that only reference file paths.