[Routine - VT] fix(FileManager): use normalized membership check for add/remove files

[winterdrive]

Pre-flight Check

Open PRs / active branches checked before selecting this fix:

• [Routine - VT] fix(provider): guard against stale groupIdx when rendering file bookmarks #78 routine/vt-fix-bookmark-stale-groupidx-260703 — touches src/provider.ts
• [Routine - VT] fix(extension): dispose treeView listeners and pending reveal timer #77 routine/vt-fix-treeview-listener-disposal-260702 — touches src/extension.ts
• chore: release v0.7.6 #76 release/0.7.6-260701 — touches CHANGELOG.md, package.json, package-lock.json (release PR, not routine)
• Various stale/merged origin/routine/vt-fix-* branches from prior days (bookmark-relpath, filesorter-tests, groupmgr-cache-miss, senddestguard, treeview-listener-disposal, watcher-new-scope, duplicate-scope) — already merged, no overlap.

This PR touches only src/core/FileManager.ts and adds a new test file src/test/unit/fileManagerRelpath.test.ts. No overlap with provider.ts, extension.ts, or any release metadata files.

Changes

FileManager.addFilesToGroup and FileManager.removeFilesFromGroup compared file paths against group.files using plain Array.includes() / Array.indexOf() against a freshly-built file:// URI. However, group.files can legitimately contain workspace-relative path strings (e.g. "src/foo.ts") instead of file:// URIs — this is the same class of bug already fixed for BookmarkManager.createBookmark in commit e12c0d9 via matchesStoredFileEntry.

Because these two FileManager methods back the MCP server's add_files_to_group / remove_files_from_group tools (mcp-server/src/tools/fileTools.ts → mcp-server/src/managers/FileManager.ts, a re-export of this class), the bug was reachable from the MCP-facing API even though the in-editor path (provider.ts) already uses the normalized matcher:

• addFilesToGroup would fail to recognize a relative-path entry as a duplicate and push a second (URI) entry for the same file instead of reporting it as skipped.
• removeFilesFromGroup would fail to find a relative-path entry and incorrectly report it as notFound instead of removing it.

Fix: both methods now use matchesStoredFileEntry (from src/core/FileEntryMatcher.ts) with the group's workspace root, matching the pattern already used by BookmarkManager and GroupFileRemoval.

Confirms this PR does not modify: command registrations, package.json contributed configuration keys, dependencies, or the tab-group serialization/storage format. Only comparison logic inside two existing methods changed; the on-disk files array shape and virtualTab.json format are untouched.

Safety Verification

Commands run locally, all passed:

• npx tsc -p ./ — passed, no errors
• npm run test (tsc -p ./ && jest --runInBand) — 26 suites / 178 tests passed, including 3 new tests in src/test/unit/fileManagerRelpath.test.ts covering: skip-on-duplicate for a relative-path entry, remove-by-relative-path entry, and notFound still reported for genuinely absent files.
• No lint or format:check script exists in package.json, so those steps were skipped.

CI / Release Gate Note

This is a daily routine Draft PR. Package version bump and CHANGELOG.md updates are intentionally deferred to the weekend release/integration PR. If CI fails solely due to the repository's version-bump release gate, that is expected release-readiness behavior for a routine PR, not a code validation failure.