Published .d.ts files use extensionless relative imports, so NodeNext consumers get any types #214

Problem

The .d.ts files published for @seamless-auth/express, @seamless-auth/fastify and @seamless-auth/nextjs import siblings without extensions (for example from "./handler", from "./session", from "./options"). TypeScript projects using "moduleResolution": "NodeNext" (or Node16) cannot resolve those, so the exported function types (for example requireAuth) degrade to any. skipLibCheck: true, the default in most templates, hides the error, so consumers silently lose type checking rather than seeing a failure.

Found while fixing the request augmentation in #213, which fixed only the augmentation import (it now uses import "./types/express.js").

Reproduction

In a scratch project with "module": "NodeNext", "moduleResolution": "NodeNext", "strict": true, "skipLibCheck": false, install the published package and import requireAuth. tsc --noEmit reports the unresolved relative imports; with skipLibCheck: true the import types as any.

Fix options

• Add .js extensions to every relative import in source (TypeScript keeps them in the emitted .d.ts), or
• Bundle the declarations (for example tsup dts: true with a single entry) so there are no relative imports to resolve.

Extend the consumerTypes tests from #213 to assert a real function type (not only the augmentation) under NodeNext with skipLibCheck: false, for all three packages.