Permission scanner misclassifies git -L arguments and shell command text as directory paths

### Describe the bug

Copilot CLI incorrectly flags parts of a shell command as directory access candidates when running `git log -L ...` with a search expression that starts with `/`.

In my case, the permission prompt displayed a synthetic "path" composed of:

- the `git log -L` search expression
- a source file path
- trailing shell text such as `&& printf`

This is not a real filesystem path. It appears the permission scanner is lexically collecting slash-prefixed command arguments and adjacent shell text, then presenting the result as an "Allow directory access" prompt.

### Affected version

GitHub Copilot CLI 1.0.73

### Steps to reproduce the behavior

Run a shell command shaped like this:

```bash
cd /REPO_ROOT && printf '%s\n' '---marker---' && git --no-pager log --oneline -L '/requestMatchers(HttpMethod).GET, "/some-route"/,+1:/project-module/src/main/java/com/example/security/SecurityConfig.java'
```

Then ask Copilot CLI to execute it under normal permissions.

### Actual behavior

Copilot CLI shows an **Allow directory access** prompt and presents a "path" that is actually a mixture of:

- the `-L` search expression
- the Java source path
- trailing shell tokens such as `&& printf`

Example of the misclassified candidate shape:

```text
/requestMatchers(HttpMethod).GET, "/some-route"/,+1:/project-module/src/main/java/com/example/security/SecurityConfig.java && printf
/**
/requestMatchers(HttpMethod).GET,
/\*\*
/,+1:/project-module/src/main/java/com/example/security/SecurityConfig.java
```

This is not a valid directory path and should not be treated as one.

### Expected behavior

Copilot CLI should not interpret `git -L` expressions or adjacent shell command text as filesystem paths.

If path scanning is needed, it should distinguish between:

- actual filesystem arguments
- regex/search expressions
- shell syntax and chained commands

### Impact

This causes unnecessary permission prompts on normal investigation commands and interrupts the workflow.

### Additional context

This looks related to other permission/path misclassification issues, especially cases where slash-prefixed strings or URL-like arguments are treated as local paths.

Reproduce the permission prompt with the provided shell command, then trace the CLI permission scanner that collects path candidates from git -L arguments and chained shell text. Compare the candidate list with the actual filesystem argument and verify that the search expression and trailing shell tokens no longer produce directory-access prompts.

Written by the indexing model from the issue text.