fix: use schema-first generic pattern for Zod type compatibility

Refactor `SignInResolverFactoryOptions` and `createSchemaFromZod` to use
`TSchema extends ZodType` instead of `ZodSchema<Output, Def, Input>`,
avoiding "excessively deep" TypeScript inference errors when multiple
Zod copies are resolved in a project.

Signed-off-by: Jon Koops <jonkoops@gmail.com>

.changeset/fix-zod-generic-auth-node.md

@@ -0,0 +1,26 @@
+---
+'@backstage/plugin-auth-node': minor
+---
+
+**BREAKING**: Refactored `SignInResolverFactoryOptions` to use a schema-first generic pattern, following Zod's [recommended approach](https://zod.dev/library-authors?id=how-to-accept-user-defined-schemas#how-to-accept-user-defined-schemas) for writing generic functions. The type parameters changed from `<TAuthResult, TOptionsOutput, TOptionsInput>` to `<TAuthResult, TSchema extends ZodType>`.
+
+This fixes "Type instantiation is excessively deep and possibly infinite" errors that occurred when the Zod version in a user's project did not align with the one in Backstage core.
+
+If you use `createSignInResolverFactory` without explicit type parameters (the typical usage), no changes are needed:
+
+```ts
+// This usage is unchanged
+createSignInResolverFactory({
+  optionsSchema: z.object({ domain: z.string() }).optional(),
+  create(options = {}) {
+    /* ... */
+  },
+});
+```
+
+If you reference `SignInResolverFactoryOptions` with explicit type parameters, update as follows:
+
+```diff
+- SignInResolverFactoryOptions<MyAuthResult, MyOutput, MyInput>
++ SignInResolverFactoryOptions<MyAuthResult, typeof mySchema>
+```

.changeset/fix-zod-generic-frontend-plugin-api.md

@@ -0,0 +1,5 @@
+---
+'@backstage/frontend-plugin-api': patch
+---
+
+Refactored the internal `createSchemaFromZod` helper to use a schema-first generic pattern, replacing the `ZodSchema<TOutput, ZodTypeDef, TInput>` constraint with `TSchema extends ZodType`. This avoids "excessively deep" type inference errors when multiple Zod copies are resolved.