Fix: Generate AddTo methods for array properties with child builders

[Copilot]

Arrays were excluded from AddTo method generation when useChildBuilders: true, despite Lists and other collections receiving both traditional and Func-based overloads.

Changes

• Added ArrayCollectionMetadata - New metadata class for array types, following existing collection metadata pattern
• Updated CollectionMethodDetector - Detect IArrayTypeSymbol and return ArrayCollectionMetadata
• Updated PropertiesStringGenerator - Generate array-specific AddTo methods:
  • Traditional: AddTo(params T[] items) using Array.Copy for concatenation
  • Child builder: AddTo(params Func<TBuilder, TBuilder>[] configures)
  • Consolidated array and concrete collection generation to reduce code duplication
• Added integration tests - New ParentWithChildArrayEntity with 4 test cases covering both constructor and settable array properties

Implementation Details

Arrays use System.Array.Copy to concatenate existing arrays with new items, preserving reference equality semantics. The implementation consolidates array and concrete collection code generation patterns while maintaining the distinct behavior for each (Array.Copy vs collection.Add).

This approach ensures:

• Reference equality is preserved when using With methods
• Multiple AddTo calls properly accumulate items
• Reduced code duplication through unified generation patterns
• All existing tests continue to pass

Example

// Before: Only WithChildren(T[] items) was generated
// After: Both overloads now available

[MakeBuilder(typeof(MyClass), useChildBuilders: true)]
public partial class MyClassBuilder { }

public record MyClass(MyChild[] ChildArray, IReadOnlyList<MyChild> ChildList);

var obj = MyClassBuilder.MyClass
    .AddToChildArray(                    // Now works for arrays
        c => c.WithName("First"),
        c => c.WithName("Second"))
    .AddToChildList(                     // Already worked for lists
        c => c.WithName("Third"))
    .Build();

Arrays now behave consistently with other collection types - multiple AddTo calls accumulate items using array concatenation.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>AddTo... methods not generated for arrays</issue_title>
<issue_description>First, thanks for adding the child builder feature. It is a great addition. Not sure if it was intentional or not, but the following doesn't generate the same methods for arrays as it does for lists.

public record MyClass
{
    public MyChild[] ChildArray { get; init; } = [];

    public IReadOnlyList<MyChild> ChildList { get; init; } = [];
}

public record MyChild
{
    public required string Name { get; init; }
}

[MakeBuilder(typeof(MyClass), useChildBuilders: true)]
public partial class MyClassBuilder
{
}
[MakeBuilder(typeof(MyChild), useChildBuilders: true)]
public partial class MyChildBuilder
{
}
```</issue_description>

<agent_instructions>remember about adding a log to a changelog. Reuse already exisitng testing classes for tests.</agent_instructions>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes AddTo... methods not generated for arrays #112

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[pmrogala]

I would prefer to use List of items and then in the build method we can use .ToArray().
THis copying mechanism sounds bad

[Copilot]

Implemented as requested in commit 5eab549. Arrays now use List internally and convert to array via .ToArray() in the Build method.

Note: This creates new array instances in With methods, breaking reference equality. See my comment on line 265 for details on the tradeoff.

[pmrogala]

I would prefer to use List of items and then in the build method we can use .ToArray().
THis copying mechanism sounds bad

[Copilot]

I've refactored the implementation to use List internally with .ToArray() conversion in the Build method (commit 5eab549).

However, this approach has a semantic tradeoff: the With methods now create new array instances instead of preserving reference equality. This causes 8 existing tests to fail because they expect BeSameAs (reference equality).

Tradeoffs:

• List approach (current): Cleaner code, better performance for multiple AddTo calls, but breaks reference equality
• Array.Copy approach (original): Preserves reference equality, but more complex code

The 4 new array child builder tests all pass. Should I:

1. Keep the List approach and update the failing tests?
2. Revert to Array.Copy to preserve existing semantics?
3. Hybrid: Use Array.Copy for With methods but List for AddTo methods?

[pmrogala]

Let's revert back to the Array backing field solution

[pmrogala]

Is it possible to reuse the same geneartion like for [concrete/interface]collectionmetada?
It looks super similar.

[Copilot]

Consolidated the array and concrete collection generation in commit 4e00e9a. Both types now use a unified pattern with conditional logic to handle the differences (Array.Copy vs collection.Add).

[pmrogala]

Is it possible to reuse the same geneartion like for [concrete/interface]collectionmetada?
It looks super similar.

[Copilot]

Consolidated the array and concrete collection generation in commit 4e00e9a. Both types now use a unified pattern with conditional logic to handle the differences (Array.Copy vs collection.Add).

[Copilot]

Let's revert back to the Array backing field solution

Reverted to array backing field with Array.Copy approach in commit dd74d64. All 111 tests now pass (the List approach had 8 failing tests due to reference equality issues).