fix(compiler): resolve inherited type references against the declaring file

[Arul1998]

Type references on component members are recorded relative to the file declaring them. When members are inherited from a base class in another directory, the references were merged into the component's metadata unchanged, and type generation later resolved them against the component's own file. This produced imports in components.d.ts pointing at nonexistent paths, broke type resolution for library consumers, and emitted duplicate aliased imports for each extending component. This affected both imported types and types declared locally in the base class's file, with any level of inheritance.

Re-anchor inherited members' type references when they are merged: relative import specifiers are rewritten to resolve from the component's directory, and base-class-local types become imports of the base class's module.

fixes #6687

What is the current behavior?

GitHub Issue Number: #6687

When a component inherits decorated members from a base class in a different directory, the generated components.d.ts resolves the members' type imports against the component's file instead of the base class's file. For the reproduction in #6687, it emits import { Validator } from "./components/data-entry/checkbox/input.types" — a path that doesn't exist in dist/types — instead of ./components/shared/input/input.types. This happens with a single level of extends (not only chains), also affects types declared locally in the base class's file, and each extending component emits its own broken duplicate import under an incremented alias. A consumer type-checking against the package gets hard TS2307/TS2305 errors.

What is the new behavior?

When inherited members are merged into a component's metadata (mergeExtendedClassMeta), their type references are re-anchored to the component's file: relative import specifiers are rewritten relative to the component's directory, and types declared in the base class's file are converted to imports of that file. Since the metadata itself is corrected, every consumer of it (components.d.ts, docs outputs, collections) gets the right paths. Shared types now emit a single correct import instead of per-component broken duplicates. References for same-directory base classes, package imports, globals, and base classes shipped in external collections are left untouched.

Documentation

N/A

Does this introduce a breaking change?

• Yes
• No

Testing

Added unit tests covering: re-anchoring relative import specifiers (including ones pointing outside the base class's tree), converting base-class-local references to imports, ./-prefixing bare specifiers, and the no-op cases (same directory, package imports, globals, node_modules base classes, members without references). Manually verified end-to-end with a project matching the issue's structure: pre-fix, tsc against the generated dist/types fails with 8 errors; with this fix it passes, and components.d.ts contains single, correct imports for both inherited-imported and inherited-local types, while non-inherited components are byte-identical.

Other information

N/A