foundry: classify dependencies relative to the project root

[rootminus0x1]

Summary

Foundry.is_dependency classifies a file as a dependency by checking for lib / node_modules components anywhere in its absolute path. When a Foundry project is checked out under a parent directory named lib — the normal layout when it's a git submodule (<repo>/lib/<project>) — every source file's absolute path contains a lib component, so all of the project's own sources are wrongly flagged as dependencies.

Dependency-aware consumers then silently skip the whole project. With Slither, the dead-code detector (and other dependency-respecting detectors) report nothing for a project nested under lib/, while the same project analyzed as a standalone checkout (e.g. in CI) reports findings — a confusing local-vs-CI divergence with no error.

Fixes #690.

Change

is_dependency now classifies the path relative to the project root (self._project_root, already on the Foundry instance) before the component check, so only lib / node_modules / configured-libs directories within the project count. Paths outside the project tree fall back to the previous behaviour.

try:
    path_parts = Path(path).resolve().relative_to(self._project_root.resolve()).parts
except ValueError:
    path_parts = Path(path).parts  # outside the project tree — classify as-is

Test

Adds tests/test_is_dependency.py: a Foundry project created under a parent lib/ directory, asserting its src/ is not a dependency while its own lib/ contracts still are. Fails on master, passes with the fix.

Notes

• Minimal change, no unrelated formatting.
• ruff check, ruff format --check, and ty check all pass.

Related: #279 — same family (dependency path-component detection vs. directory layout), but the opposite failure (dependencies not found when hoisted in a monorepo).

[CLAassistant]

All committers have signed the CLA.