feat(scanner): Resolve JS/TS workspace imports

[reneleonhardt]

What does this PR do?

Resolve local JS/TS imports from package, pnpm, Bun, and Deno workspace manifests. Ambiguous, external, escaping, and unsupported targets remain unresolved.

This lets a sandboxed coding agent run codemap --deps ../gitbutler and follow workspace packages without invoking a JavaScript runtime or package manager.

This PR is complete and independently mergeable; Rush workspace support is a finished follow-up (+167/-1).

Type of change

• Bug fix
• New feature
• New language support
• Documentation
• Other (describe below)

Checklist

• I've tested this locally with go build && ./codemap .
• I've read CONTRIBUTING.md; this does not add a new language.
• Documentation is unchanged because existing dependency output gains local edges.

Additional notes

Focused scanner tests cover Node, pnpm, Bun, Deno, hybrid, ordered workspace exclusions, filtered, conditional-export, ambiguity, and fail-closed boundaries.

The 1,424 additions are the minimum complete shape:

• 40 integration lines preserve the existing single scan
• 976 lines implement one dependency-free resolver across four workspace dialects plus conditional and patterned exports, source remapping, and fail-closed safety checks
• 408 shared-fixture test lines prove those boundaries.

Removing or splitting any slice would drop supported behavior, safety coverage, or leave a non-useful intermediate.

Focused verification:

go test ./scanner -run 'Test.*(JSWorkspace|Workspace|Pnpm|JSONC)' -count=1

The publication tip also passes the full race/coverage, vet, Staticcheck, build, and Linux Go 1.24 checks.

Developed with carefully directed, manually reviewed AI assistance.

Co-Authored-By: GPT-5.6 Sol codex@openai.com

[JordanCoin]

Reviewed — this is a lot of real resolution logic (package.json exports/imports, # subpath imports, pnpm workspaces, Deno import maps, tsconfig rootDir/outDir remapping), and it's the right answer to JS/TS being the biggest blind spot in the graph. Nil-receiver safety on jsWorkspaceResolver.resolve so fuzzyResolve can keep passing nil is a nice touch.

One thing worth a look before it lands:

When any JS file is present, the file scan drops the Only filter for the entire repo. scanOnly = nil widens ScanFiles to every non-excluded file so the resolver can see package.json/tsconfig.json/pnpm-workspace.yaml, then files is narrowed again afterwards. On a repo configured with e.g. only: [".ts"], we now walk and materialize FileInfo for everything, and buildFileIndex — which builds an entry per path suffix — runs over allFiles… actually it runs over the narrowed files, so that part is fine, but the walk and the allocation aren't. Scanning with Only plus the handful of manifest basenames would get you the same inputs without the whole-repo widening.

Smaller: MatchesFilters(file.Path, ...) here is passed a native-separator path, whereas filterAnalyses passes filepath.ToSlash(analysis.Path). Harmless while Only is extension-only, but it's an inconsistency that'll bite the first time someone puts a / in a filter on Windows.

Ordering note: this touches the same buildFileGraphFromFilteredAnalysesWithCargoMetadata body that #97 renames and #93 adds cancellation checks to, so it's probably the last of the scanner PRs to land.