fix(@nestjs/graphql): emit clearer error when nested object type is used in mapped input

[yogeshwaran-c]

PR Checklist

• The commit message follows our guidelines
• Tests for the changes have been added
• Docs have been added / updated (not applicable — error-message change only)

PR Type

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

Issue

Closes #2841

What is the current behavior?

When a class decorated with @ObjectType() is referenced (directly or transitively) by a field of an @InputType(), schema construction fails with:

Cannot determine a GraphQL input type ("ClassB") for the "propName". Make sure your class is decorated with an appropriate decorator.

This is what happens for the scenario described in #2841: PartialType(ClassA, InputType) re-decorates ClassA as an input type, but any nested @ObjectType() field of ClassA is still an object type, and the schema builder rejects it with a generic error that does not explain what actually went wrong.

What is the new behavior?

The InputTypeFactory now detects the specific case where the referenced class is already registered as an @ObjectType() and throws a clearer, actionable error:

Cannot use "ClassB" as a GraphQL input type for the "propName" field because it is decorated with @ObjectType(). Input types cannot reference object types. Create a separate class decorated with @inputType() for "ClassB", or pass InputType as the second argument to the mapped-type helper (e.g. PartialType(ClassB, InputType)) so that it is registered as an input type.

This names the offending class, explains the root cause, and points users to both of the valid fixes (a dedicated @InputType() class, or using the mapped-type helper's decorator override on the nested type). The original generic message is preserved for all other cases (unregistered types, scalars the builder cannot resolve, etc.).

A focused unit test for CannotDetermineInputTypeError covers the new and preserved branches.

Does this PR introduce a breaking change?

• Yes
• No

The public error type (CannotDetermineInputTypeError) gains an optional third constructor argument; existing call sites and error handling are unaffected.

Other information

The more invasive alternative — cascading the second-argument decorator override in PartialType / PickType / OmitType / IntersectionType to nested types — would silently change the decoration of classes declared elsewhere and affect the schema globally. This PR deliberately limits the scope to an error-message improvement so users are immediately told what to do.