Fix: keep original pattern when no rule matches

[Simontakeasit]

Summary

This change preserves the original requested pattern when PermissionNext.evaluate() falls back to the default ask rule.

Previously, the fallback rule always returned pattern: "*", which could lead to misleading logs, debugging output, and UI display.

Changes

• Keep the caller-provided pattern when no permission rule matches
• No behavior change in permission decisions (still defaults to ask)

What does this PR do?

This PR improves the fallback behavior of PermissionNext.evaluate() when no permission rule matches.

Previously, when the evaluation logic fell back to the default ask rule, the returned result always used pattern: "*", regardless of the actual pattern requested by the caller. While the permission decision itself was correct, this behavior could lead to confusing or misleading information in logs, debugging output, and any UI components that rely on the evaluated permission result.

With this change, the fallback path now preserves the original caller-provided pattern, ensuring that the evaluation result more accurately reflects the real request context. Importantly, this PR does not change any permission decision logic — the system still defaults to ask when no rule matches — it only improves the correctness and clarity of the returned metadata.

How did you verify your code works?

When no permission rule matches, the evaluation result now returns the original input pattern instead of "*".

[github-actions]

Hey! Your PR title permission: keep original pattern when no rule matches doesn't follow conventional commit format.

Please update it to start with one of:

• feat: or feat(scope): new feature
• fix: or fix(scope): bug fix
• docs: or docs(scope): documentation changes
• chore: or chore(scope): maintenance tasks
• refactor: or refactor(scope): code refactoring
• test: or test(scope): adding or updating tests

Where scope is the package name (e.g., app, desktop, opencode).

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, no duplicate PRs found that are directly addressing the same issue as PR #7937.

The search results show several permission-related PRs, but they address different aspects:

• PR fix: permission pattern mismatch for tool-output directory #7875 deals with permission pattern mismatch for tool-output directory (different scope)
• PR feat: glob pattern-based external_directory permission #5841 and feat: add granular external_directory permission configuration #5905 are about glob pattern-based permissions (feature PRs, not bugfixes)
• Other results are related to bash permissions or documentation

None of these are duplicates of the current PR, which specifically focuses on preserving the original pattern when PermissionNext.evaluate() falls back to the default ask rule.