Fix nested readonly collection ctor parameters

[rosebyte]

Fixes #131399

Problem

The configuration binder source generator silently bound null/default for a nested member whose type's sole member is a constructor parameter of a read-only collection type:

public record Inner(IReadOnlyList<string> Values);

public class Outer
{
    public Inner? Nested { get; set; }          // bound null
    public InnerStruct Struct { get; set; }     // bound default
}

The reflection binder binds both correctly, so this was a silent divergence between the two engines: no diagnostic, no exception, just missing configuration at runtime.

#131358 fixed the equivalent top-level case (config.Get<Inner>()). The nested case remained broken, and this is a pre-existing gap rather than a regression from that change.

Root cause

Two independent bugs sharing one symptom.

1. Reference types. EmitBindImplForMember skipped any complex member with no bindable members. But a type with a parameterized constructor binds its parameters in the generated Initialize method regardless of what other members it has. Thanks to #131358 InitializeInner was being emitted and CanInstantiate was true; nothing ever called it.

The guard is now extracted into IsBindableAsMember, with the missing term added: a type that can be instantiated is bindable through its constructor even with no bindable members of its own, provided the member can actually be assigned. The near-duplicate logic in IsPropertyReboundInBindCore now calls the same helper, so the two cannot drift apart.

2. Value types. Relaxing the guard alone gets you through the door into an empty room, because two conditions both had to change:

• EmitBindingLogicForComplexMember hard-codes InitializationKind.None for value types, since a struct behind a property getter is a copy and cannot be bound in place.
• EmitBindingLogic then early-returns on !HasBindableMembers unless the initialization kind is something other than None.

Such a type is created outright by Initialize, so the value-type branch now short-circuits to SimpleAssignment and assigns that instance directly to the member.

The struct case was arguably worse than plain default: a non-nullable struct parameter threw ParameterHasNoMatchingConfig when the section was absent, and silently bound default when it was present — close to backwards. This corrects the present case; the absent-section throw stays, matching every other non-nullable parameter.

canSet

Both terms require the member to be settable. For a get-only or init-only member there is nothing to assign, so un-skipping it emitted only a dead block plus a spurious boundThroughConstructor parameter on BindCore. For value types this is a small behavioural change worth calling out: dead blocks previously emitted for get-only struct members are gone.

Generated code

Before, for class Outer { public Inner? Nested { get; set; } }:

public static void BindCore(IConfiguration configuration, ref Outer instance, ...)
{
    // Nested was skipped entirely
}

After:

if (AsConfigWithChildren(configuration.GetSection("Nested")) is IConfigurationSection section)
{
    instance.Nested = InitializeInner(section, binderOptions);
}

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR fixes a configuration binding source-generator parity gap where certain nested complex members were skipped during generated binding, leaving them null/default instead of being constructed and populated as the reflection-based binder would.

Changes:

• Refactors the “should we emit binding code for this complex member?” decision into IsBindableAsMember and applies it consistently to both EmitBindImplForMember and IsPropertyReboundInBindCore.
• Updates value-type complex-member binding to directly assign the instance created by Initialize(...) when the type has no bindable members beyond constructor parameters.
• Adds new regression tests covering nested binding for both reference types and value types (including nullable structs), plus a reflection-binder test for the same shape.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/libraries/Microsoft.Extensions.Configuration.Binder/tests/SourceGenerationTests/GeneratorTests.cs	Adds generator regression tests for nested binding of “sole read-only collection ctor parameter” shapes (class + struct).
src/libraries/Microsoft.Extensions.Configuration.Binder/tests/Common/ConfigurationBinderTests.TestClasses.Collections.cs	Introduces test types used to validate nested binding behavior in reflection-binder tests.
src/libraries/Microsoft.Extensions.Configuration.Binder/tests/Common/ConfigurationBinderTests.Collections.cs	Adds a reflection-binder regression test verifying nested binding for the same type shapes.
src/libraries/Microsoft.Extensions.Configuration.Binder/gen/Emitter/CoreBindingHelpers.cs	Fixes emitter logic so nested members that bind via constructor parameters are no longer skipped; adds a value-type fast path to assign initialized instances.