count good faith introspection fields on repeated fragment spreads - #4515

a named fragment that is spread more than once gets around the good faith cap on __Type.fields / inputFields / interfaces / possibleTypes:

query {
  __schema { a1: types { ...T } a2: types { ...T } ... a120: types { ...T } }
}
fragment T on __Type { fields { type { name } } }

# schema with 300 types x 20 fields
inline, 2 selections:                 BadFaithIntrospectionError: __Type.fields is present too often!
fragment, 120 spreads (2.5 KB query): no error, 14.6 MB response, 5.8 s
fragment, 120 spreads, patched:       BadFaithIntrospectionError: __Type.fields is present too often!

OperationValidator.checkFragmentSpread only traverses a fragment on its first spread in an operation. later spreads add the cached FragmentComplexityInfo field count and depth, so the 500 field / 20 depth limits still hold (120 spreads x 4 fields stays under 500), but checkGoodFaithIntrospection never sees the fields inside them, and every re-spread repeats the full types x fields walk without being counted.

FragmentComplexityInfo now also keeps the good faith keys counted during the fragment's first traversal (nested fragments included), and a later spread counts them again, so it behaves the same as writing the selection inline. fragments without cycle forming fields, like TypeRef and InputValue in the standard introspection query, record nothing and are unaffected. this is the cached path that #4490 did not cover; that change handled __schema reached through a fragment's first traversal.