fix(parser): resolve dotted-stem relative imports in JS/TS and Dart

Path.with_suffix() replaces the final path suffix rather than appending
one, so the JS/TS/TSX/Vue relative-import resolver mistook a dotted
stem for an existing extension: `./outlet.entity` probed `outlet.ts`
and never found `outlet.entity.ts`. Dotted stems are the dominant
NestJS convention (*.entity.ts, *.service.ts, *.controller.ts,
*.guard.ts, *.module.ts), so relative imports between such files
silently produced no IMPORTS_FROM edge, and importers_of returned a
confident, wrong zero for the real target.

Switch the primary probe to extension-append (Path(str(base) + ext)),
matching the idiom tsconfig_resolver.py already used for alias
imports. Keep a `with_suffix` fallback, but only when the import
already ends in .js/.jsx/.mjs/.cjs — NodeNext/ESM TypeScript writes
`./foo.js` for a file that is `foo.ts` on disk, which is the one case
where replacing the suffix is correct.

The Dart resolver's `.dart`-append fallback had the same bug shape
(`base.with_suffix(".dart")`); fixed the same way. Surveyed the other
relative/dotted-path resolvers in the same function (Python, Rust) —
both build their candidate path from module-name segments that can't
contain a literal dot, so `with_suffix` is safe there and was left
alone.

Adds three tests: the dotted-stem regression (red against the
unpatched resolver), a NodeNext .js->.ts case that must keep passing
so a future simplification that drops the ESM fallback goes red, and
the Dart sibling.