Resolve permission profiles with explicit execution-host path context

[copyberry]

Resolve permission profiles with explicit execution-host path context

Why

Permission paths need to follow the execution host's path conventions and home directory. Literal directory names containing glob syntax must not change the meaning of deny patterns, and profile availability checks need to account for configured workspace roots.

What changed

• Use ConfigPathContext to compile built-in and custom profiles, returning the resolved profile and deduplicated PathUri workspace roots. Materialize configured roots while retaining runtime workspace symbols.
• Use the same compiler for configuration loading, persisted profile validation, and profile catalogs. Resolve roots against the requested cwd when listing profiles.
• Resolve home-relative scoped rules using the supplied home directory and reject unsafe directory prefixes when constructing globs.
• Share workspace-root materialization across native paths and URIs. Deny the affected root when a workspace glob cannot be safely resolved, and clear grants for legacy home-relative workspace denials whose target is unknown.

Testing

Add coverage for POSIX, Windows, and UNC path resolution, inherited workspace roots, scoped home denials, missing home context, and conservative denial behavior for unsafe globs. Add an app-server test verifying that profile availability reflects the requested cwd.

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}