Type::multiplicity is derived through alias and reference memberships, so both multiplicity-domain checks fire on valid models #802

Version: 2026-08 (jupyter-sysml-kernel 0.62.0, validate-kerml over the shipped
standard library); Type_multiplicity_SettingDelegate is unchanged on master at 5cca16d8.

Minimal reproduction

package P {
    private import ScalarValues::*;
    class T;
    class K { feature f : T { multiplicity m [1..2]; } }
    class C { alias m for K::f::m; }
    class E {
        multiplicity em [1..4];
        feature k : Integer { alias a for em; }
        feature v : Natural = em;
    }
}

Expected

No diagnostics. None of C, k or v owns a multiplicity: C and k each own an alias
Membership whose memberElement is a multiplicity owned elsewhere, and v owns a
FeatureValue whose FeatureReferenceExpression reaches em through a reference Membership.
KerML 1.1 8.3.3.1 derives Type::multiplicity as ownedMember->selectByKind(Multiplicity)->any(true),
and ownedMember is ownedMembership.ownedMemberElement — the members of OwningMemberships
only. An alias or reference membership has no ownedMemberElement, so all three types have an
empty multiplicity, and both validateClassifierMultiplicityDomain and
validateFeatureMultiplicityDomain are satisfied.

Actual

alias.kerml:5:5: error: Multiplicity must not have a featuring type
alias.kerml:8:9: error: Multiplicity must have same featuring types as it feature
alias.kerml:9:31: error: Multiplicity must have same featuring types as it feature

The same alias inside a subclass (class F :> K { alias mf for f::m; }) and inside a struct
are reported alike.

Cause

org.omg.sysml.logic Type_multiplicity_SettingDelegate.getMultiplicityOf:

return (Multiplicity)type.getOwnedMembership().stream().
        map(Membership::getMemberElement).
        filter(Multiplicity.class::isInstance).
        findFirst().orElse(null);

maps every ownedMembership — alias and reference memberships included — through
Membership::getMemberElement, so the first Multiplicity reachable through any membership
becomes the type's own. For C that is K::f::m, a multiplicity featured by f, and
KerMLValidator.checkClassifier reports its featuring type; for k and v it is em, a
classifier multiplicity with no featuring type, and checkFeature reports that it differs from
the feature's {E}.

This is the same mistake fixed in TypeUtil.addMultiplicityTo by #708, where a nested alias was
counted as an existing multiplicity: an alias membership is an ownedMembership but not an
OwningMembership, so its member is not an owned member of the type.

Suggested fix

Derive multiplicity from ownedMember (equivalently, filter ownedMembership to
OwningMembership and read ownedMemberElement) as 8.3.3.1 does:

return type.getOwnedMembership().stream().
        filter(OwningMembership.class::isInstance).
        map(m -> ((OwningMembership) m).getOwnedMemberElement()).
        filter(Multiplicity.class::isInstance).
        map(Multiplicity.class::cast).
        findFirst().orElse(null);