fix: add typesVersions for subpath type resolution

[Royal-lobster]

Summary

• Add typesVersions field to package.json for nestjs and nextjs subpath exports
• TypeScript with moduleResolution: "node" ignores exports maps for type resolution — typesVersions provides the fallback

Follows up on #8 (CJS support). The CJS build fixed runtime resolution but TypeScript still couldn't find types for @iqai/alert-logger/nestjs without manual tsconfig paths.

Test plan

• Existing tests pass
• Verified TypeScript resolves @iqai/alert-logger/nestjs types without tsconfig paths workaround

🤖 Generated with Claude Code

Closes #15

[gemini-code-assist]

Code Review

This pull request introduces typesVersions to the package.json to support subpath type resolution for NestJS and NextJS integrations, along with a corresponding changeset. A review comment suggests adding a catch-all wildcard mapping within the typesVersions block to ensure that the root entry point's types remain resolvable, as the current configuration might cause TypeScript to ignore the top-level types field.

[gemini-code-assist]

When using typesVersions for subpath mapping with a wildcard version range (*), TypeScript may ignore the top-level types field for the root entry point if it doesn't find a match within the mapping. To ensure the root types remain resolvable for all users, it is a best practice to include a catch-all mapping or an explicit entry for the root.

Consider adding a wildcard mapping to the end of the block:

  "typesVersions": {
    "*": {
      "nestjs": ["./dist/integrations/nestjs/index.d.ts"],
      "nextjs": ["./dist/integrations/nextjs/index.d.ts"],
      "*": ["./dist/index.d.ts"]
    }
  },