fix: relativise absolute --file path against root for uv monitor

[snyk-will]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages
  are release-note ready, emphasizing
  what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)
• Includes product update to be announced in the next stable release notes

What does this PR do?

Fixes UNIFY-1419: UI-applied ignores were silently no-op'd for UV projects in CI when --file was an absolute path (the GitLab CI default). snyk monitor was registering the project under one name (:/builds/.../pyproject.toml) and snyk test was looking it up under another (:pyproject.toml), so the test-time project lookup missed and the policy never loaded.
The fix changes getResolvedTargetFile in the TS UV plugin to relativise the lockfile path against the project root before swapping the basename to pyproject.toml, matching the npm/yarn workspaces convention. Monitor and test now send byte-identical project identities for the same uv.lock, regardless of whether --file was absolute or relative.

Where should the reviewer start?

src/lib/plugins/uv/index.ts — the new getResolvedTargetFile(root, targetFile) function is the whole fix.

How should this be manually tested?

In an org with enableUvCLI enabled, against any UV project:
PROJ=$(pwd)
snyk monitor --org= --file=$PROJ/uv.lock

Apply an ignore on one vulnerability in the UI

snyk test --org= --file=$PROJ/uv.lock
Expected: the test summary shows the ignored vuln as Ignored: 1, not Open. Before this fix it would show as Open because the test lookup couldn't find the project.

What's the product update that needs to be communicated to CLI users?

UV (early access): UI-applied ignore policies now apply correctly when snyk monitor and snyk test are invoked with an absolute --file path

Risk assessment (Low)

Gated behind uv feature flag

What are the relevant tickets?

https://snyksec.atlassian.net/browse/UNIFY-1419

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

	Warnings
⚠️	You've modified files in src/ directory, but haven't updated anything in test folder. Is there something that could be tested?

Generated by 🚫 dangerJS against aaecffc

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Conditional Relativization Bug 🟡 [minor] The getResolvedTargetFile function returns targetFile immediately if its basename is not uv.lock (line 125), bypassing the relativization logic. If a user provides an absolute path to a pyproject.toml file via the --file argument, the project identity will remain an absolute path. This persists the identity mismatch issue in CI environments where absolute paths are the default. if (path.basename(targetFile) !== UV_LOCKFILE_NAME) { return targetFile; }

📚 Repository Context Analyzed This review considered 4 relevant code sections from 4 files (average relevance: 1.00) package.json (lines 1-227) package-lock.json (lines 19502-19797) dangerfile.js (lines 1-111) src/lib/plugins/uv/index.ts (lines 1-161)

🤖 Repository instructions applied (from AGENTS.md)