fix(permission): ask should prefer most specific path rule for relative paths

[ventsislav-georgiev]

Problem

PermissionNext.ask evaluated only the raw incoming pattern. When tools passed relative paths, absolute path-scoped rules could lose to broad wildcard rules.

Expected

Path-scoped rules should apply consistently whether the tool path is relative or absolute, and more specific rules should win over generic ones.

Repro

1. Configure edit: "allow" globally and a scoped deny/allow rule under a specific directory.
2. Trigger an edit using a relative path inside that directory.
3. Observe wildcard behavior can override the scoped intent without absolute evaluation + specificity selection.

Proposed fix

In PermissionNext.ask, evaluate both relative and worktree-resolved absolute candidates, then choose the decision from the longest matched rule pattern.

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• No issue template was used. Please resubmit using one of the three required templates: Bug Report, Feature Request, or Question. The current format uses custom headings that don't match any template.
• If this is a bug report, please use the Bug Report template which requires a Description field and reproduction steps in the expected format.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of existing issues. Please check:

• Path-based read permissions not enforced; catch-all rules always take precedence #13646: Path-based read permissions not enforced; catch-all rules always take precedence (same core issue: path-scoped permission rules losing to broader wildcard rules)
• Read permission doesn't look to match when the agent uses ../.. paths #11059: Read permission doesn't look to match when the agent uses ../.. paths (similar: relative path handling in permissions)
• Permission edit patterns #13872: Permission edit patterns (related: path pattern matching in edit permissions not working as expected)

If you believe this was flagged incorrectly, please let a maintainer know.

[ventsislav-georgiev]

Closing as duplicate of #13646, which tracks the same core permission-path precedence issue.

Related references: #11059 (historical, closed) and #13872 (similar edit-pattern behavior).
Implemented fix is in PR #14540.