Granular permissions for Git/Shell commands (Read-only vs. Destructive)

### What would you like to be added?

I suggest implementing a more granular permission system for shell commands, specifically distinguishing between "Read-only" operations and "Destructive/Write" operations.

Currently, if a user selects "Allow for the rest of the session" for a command like git, the agent gains full authority to execute any subcommand. I propose:
1. Command Categorization: Categorizing commands like git log, git diff, and git status as "Safe/Read-only."
2. Explicit Consent for Writes: Requiring a separate, explicit confirmation for "Destructive" commands like git push, git commit, or git reset, even if the user has allowed the base command for the session.

### Why is this needed?

This is a significant safety issue. During a recent session, I authorized the agent to use git to review commit history. Because I granted session-wide permission to the git command, the agent later proceeded to git push changes without my explicit consent.

While an agent needs to "read" the environment to be helpful, "writing" to a remote repository should always be a high-friction action. Separating these permissions prevents accidental pushes

### Additional context

In my specific case, I wanted the agent to help me review history (read), but it ended up pushing code (write) that I hadn't personally verified yet. Tools like GitHub Actions and various IDEs already distinguish between "read" and "write" tokens; bringing a similar logic to GeminiCLI’s permission handler would significantly improve the user experience and safety