fix: clone fields array in buildClassMetadata to avoid dual-type leakage

[raphyabak]

Summary

Fixes #1810

MetadataStorage.buildClassMetadata() looks up the cached fields array for a class definition's target and assigns it directly to def.fields by reference:

const fields = this.fieldsCache.get(def.target) || [];
fields.forEach(field => { /* ... */ });
def.fields = fields;

A class decorated with both @ObjectType() and @InputType() shares a single target, so buildClassMetadata() is called once for the object-type definition and once for the input-type definition, and both end up with def.fields pointing at the exact same array instance.

When a @FieldResolver() is registered for that class, buildFieldResolverMetadata() pushes a new field onto the object type's fields array. Because the input type's fields array is the same reference, that push leaks into the input type too — and buildSchema() then throws CannotDetermineGraphQLTypeError while trying to resolve the field-resolver-added field as an input type field.

Fix

Clone the array before assigning it to def.fields, so each class metadata definition gets its own independent array:

def.fields = [...fields];

Test plan

• Added a regression test in tests/functional/metadata-storage.ts reproducing the exact dual-type + @FieldResolver scenario from the issue. Confirmed it fails with the reported CannotDetermineGraphQLTypeError against the unpatched code, and passes with the fix.
• Ran the full test suite (npx jest): 30 suites, 490 tests (489 previously existing + 1 new), all passing.
• npx eslint and npx prettier --check on the changed files: clean.
• npx tsc --project ./tests/tsconfig.json --noEmit: clean.