Bug: `concretize` logic mis-handles `Trait` vs `Principal` types

While reviewing the concretize function in clarity, I noticed what appears to be a bug in the way it initializes and checks the is_principal flag.

Currently, the code initializes is_principal = true before iterating through the set of types. This means that if the set contains a Trait, the function will always throw an error, because the check assumes principals were already present even when they were not.

If the ListUnionType contains a Trait, the function may incorrectly raise an error.

This behavior looks unintended, since the initialization does not reflect the actual contents of the set.

Multiple traits are also silently collapsed, which may not be correct?

Impact:

Fixing this would change the type-checking behavior of Clarity. Because of this, a fix would likely be consensus-breaking (maybe?). Could we release a fix as part of Clarity 4?

https://github.com/stacks-network/stacks-core/blob/e6487f6aa8de3cb97cf20fb7ce1c3fd2d931b773/clarity/src/vm/types/signatures.rs#L829-L871

Start in clarity/src/vm/types/signatures.rs around lines 829-871 and trace how concretize initializes and checks is_principal for ListUnionType inputs. Reproduce cases containing Trait, Principal, and multiple Traits, then add or update focused Clarity type-checking tests so the intended behavior is explicit and the possible consensus-breaking impact is reviewed.