Avoid rendering client projections during merge

[iuliiasobolevska]

Summary

• deduplicate client projections by generated package and type name
• avoid JavaFile.hashCode() rendering complete source files during every accumulator merge
• add regression coverage for generated-type identity and large projection merges

What was repeated

The projections were not being regenerated or rewritten to disk on every merge. Each projection already existed as an in-memory JavaFile, but the old .distinct() call invoked JavaFile.hashCode(), which renders the complete Java source. Because results are merged incrementally, every merge rendered all previously accumulated projections again solely to deduplicate them.

This change identifies a generated file by (packageName, typeName) instead. That pair determines its output path, so deduplication no longer needs to render the source. The first projection for an identity still wins, and equal simple names in different packages remain distinct.

Performance

An isolated CLI benchmark against the same 3.7 MB consumer schema measured a median of 113.61 seconds on master and 5.39 seconds with this change for 9,000 generated files—a 21x reduction. The two 57 MB output trees were identical; all 5,253 generated client files were byte-for-byte unchanged.

The focused regression exceeded its five-second bound before the change and passes after it.

This removes the dominant repeated source-rendering cost. The merge still performs repeated list concatenation and distinctBy scans; changing the accumulator shape is separate follow-up work.

Verification

• :graphql-dgs-codegen-core:test passed
• Kotlin main and test formatting passed