desloppify --lang typescript does not resolve tsconfig `paths` aliases; `orphaned` (and import-graph detectors) report false positives

[srt0422]

Title: --lang typescript scan does not resolve tsconfig paths aliases, producing false orphaned findings

Version

desloppify 1.0 (installed via pipx). Command: desloppify --lang typescript scan.

Problem

When scanning a TypeScript project that uses tsconfig path aliases, desloppify does not resolve
the compilerOptions.paths mapping. Files imported via an alias therefore appear to have zero
importers and are flagged by the orphaned detector as dead code.

Repro (conceptual shape, not this repo's code):

// tsconfig.json
{ "compilerOptions": { "paths": { "@/*": ["./src/*"] } } }

// src/pages/example.tsx
import ExampleView from '@/views/example/ExampleView'   // resolves to ./src/views/example/ExampleView

src/views/example/ExampleView is reported as orphaned ("zero importers, not an entry point"),
even though src/pages/example.tsx imports it. The alias is never mapped to ./src/, so the
import is never counted.

Two concrete, verifiable false positives (any aliased project)

1. A build entry point invoked by name (package.json script / build script / Make target) is
   reported orphaned because it has no import importer.
2. A view imported by a page through the @/... alias is reported orphaned despite being the
   sole direct importer — the importer is invisible because the prefix is unresolved.

Measured blast radius

On a single TypeScript project with the @/* -> ./src/* mapping, 113 of 122 orphaned
findings were false positives caused by this alias blindness. Only 8 were genuine (referenced
nowhere) plus 1 more genuine view that had been orphaned by an earlier feature removal. Every
file had a real importer or was a script/config-referenced entry point.

Relation to other detectors

Any detector built on the project's import graph is affected on aliased projects, not just
orphaned. Specifically:

• test_coverage's transitive_only classification — aliased imports are invisible, so coverage
  edges are lost.
• facade — files re-exported through alias barrels can appear to have no downstream consumers.
• single_use — an alias-prefixed single import is counted as zero uses.

No workaround available

desloppify config exposes no path-mapping option, so there is currently no way to tell the
scanner how to resolve aliases. Users must either tolerate the false positives or manually
suppress them one-by-one.

Suggested fix

Add support for reading compilerOptions.paths from tsconfig.json (and the equivalent in other
languages' module-resolution configs) and resolving alias-prefixed imports against the mapped
base before computing the import graph.

When reporting repro, please describe the npm package shape yourself (this report intentionally
omits repository source and local paths).