Reject identity comparison between distinct concrete types

[SeanTAllen]

is and isnt between two distinct concrete entity types (any pair drawn from class, actor, primitive, struct) can never be true. The compiler now rejects these comparisons at compile time instead of silently folding them to false.

The rule is intentionally narrow: it fires only when both operand types resolve to a single concrete nominal definition. Comparisons involving traits, interfaces, unions, intersections, tuples, or type parameters continue to compile, since a future code change to those structural type sets could make the comparison meaningful. Two reifications of the same generic class (Array[U64] vs Array[U32]) share a single root entity definition and are also not flagged; type-argument disjointness is left to follow-up work. Two object end literals at distinct source locations synthesize different anonymous classes and are flagged.

Closes #1977

[SeanTAllen]

Deferred scope: unions

This PR only flags is/isnt when both operand types are a single concrete nominal. Unions are deliberately out of scope — e.g., c is u where c: C and u: (D | E) (all three distinct concrete types) is not flagged today, even though the comparison is provably false.

Extending the rule to unions whose members are all concrete and collectively disjoint from the other operand would catch more cases, at the cost of more complex reasoning. Worth discussing as a follow-up.

[SeanTAllen]

Deferred scope: tuples

Tuples are also out of scope for this PR. (c, d) is (e, f) where the element types are pairwise disjoint concrete types is not flagged today.

Extending the rule to tuples whose elements are pairwise disjoint concrete types would be a natural follow-up. Worth discussing.