Absolute-path permission rules never match (tool patterns are worktree-relative)

[czk]

Permission rules written as absolute paths never take effect. Tools produce patterns via path.relative(worktree, filePath), so a path like /czk/mem/facts/me.md in a project at /czk/mem arrives as:

• inside the worktree: facts/me.md (relative)
• outside the worktree: ../../czk/... (traversal)
• no git context: czk/... (de-rooted)

So a rule like {"edit": {"/czk/**": "allow"}} can never match, and users get repeated permission prompts despite having allowed the path.

Expected: absolute rules match the actual file path. Actual: only the relative form is evaluated (packages/opencode/src/permission/index.ts, evaluate()).

Seen on v1.18.30 (dev @ f69bece).

[github-actions]

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

• Any read or edit permission rule written as an absolute path (~/.ssh, ~/.aws, /etc/hosts, etc.) silently never matches, including MDM managed rules #48049: Same root cause — absolute/~ permission rules never match because tools pass worktree-relative paths; includes detailed root cause analysis of permission/index.ts and tool/read.ts/tool/edit.ts
• Permission read/edit rules with absolute path patterns are silently ignored (matching appears workspace-relative only) #46133: Same bug reported for read/edit absolute path patterns being silently ignored (workspace-relative matching only)
• permission.edit patterns are matched against worktree-relative paths — absolute/~ patterns silently never match (fail-open for deny rules) #40945: Same root cause traced to write.ts, edit.ts submitting worktree-relative paths, with identical fail-open security implications
• write/edit/read submit relative paths so absolute and ~ permission rules never match out-of-worktree files #41067: Same issue — write/edit/read submit relative paths so absolute and ~ permission rules never match out-of-worktree files