Show the path from where the skill is loaded

[rumpl]

[docker-agent]

Assessment: 🟢 APPROVE

This PR introduces a clean pkg/path package (RelativeTo, ShortenHome, ShortenHomeDir, IsWithin) to replace ad-hoc path-shortening logic, and plumbs the skill load path through the skills dialog. The logic is correct: IsWithin properly guards against prefix-spoofing (e.g. /home/user2 wrongly matching /home/user), and ShortenHomeDir handles edge cases like the exact home-directory match. No high or medium severity issues found. Two minor observations are left as inline comments.

[docker-agent]

[LOW] ShortenHome calls os.UserHomeDir() on every invocation

ShortenHome calls os.UserHomeDir() directly on each call, which involves an environment variable lookup or syscall each time. The previous ShortenPath helper used the cached result from paths.GetHomeDir() (an atomic pointer). Since this function is called from multiple TUI rendering paths (directorytree, editfile, listdirectory, readfile, readmultiplefiles, searchfilescontent) which may be invoked on every render frame, this is a minor performance regression. Consider caching the home dir at package init or accepting it as a parameter (as ShortenHomeDir already does).

[docker-agent]

[LOW] skillLoadedFrom: RelativeTo may return a verbatim non-absolute path

When s.Local == true, skills.IsHomeSkillPath(path) is false (project-local skill), and path is not absolute, pathx.RelativeTo(path, cwd) returns the path cleaned but verbatim (since RelativeTo only relativizes when both paths are absolute). In production, loadSkillFile always produces an absolute BaseDir via filepath.Dir(path), so this edge case shouldn't arise. However, there's no guard/assertion enforcing this invariant. A defensive check (if !filepath.IsAbs(path)) could make the assumption explicit and prevent a confusing display string if the invariant is ever violated.