[Feature]: Implied relationship computation (KerML §8.4.2)

[antoineatstariongroup]

Description

KerML §8.2.3.5.1 presumes membership / importedMembership / inheritedMembership are computed
"including memberships resulting from implied Relationships". The corpus is exported without them,
so the SDK must compute them. Today excludeImplied is a no-op — nothing populates isImplied.

Four categories of semantic constraint (§8.4.2), by name: Specialization (175), Redefinition (15),
TypeFeaturing (7), BindingConnector (11). Only check* rules count.

Design

Computed on the fly in a separate layer. POCO/DTO stay a faithful match to the XMI; Extend stays a
transcription of the OCL. isImpliedIncluded stays false — no model mutation.

Tasks

• Generate the table from the OCL — ImpliedRelationshipTable (85 unconditional, 63 guarded,
  60 in a NotCovered manifest). Subclassification-vs-Subsetting is hard-coded in the template;
  the OCL does not carry it.
• LibraryTypeIndex — project-scoped, qualified-name lookup over the library ownership tree.
  Must NOT go through resolve (bootstrap cycle). Depends on: library models loaded and reachable by qualified name — satisfied today by loose XMI behind IExternalReferenceService; source is pluggable (directory / kpar / remote).
• Guard predicates for the 63 guarded rows + §8.4.2 redundancy reduction (rules 1 and 2; neither
  applies to Redefinitions).
• Set A (~12 rules, no library needed) — removes the VariantMembership patch in
  QueryRedefinedFeatureScope.
• Set B — implied Redefinitions (15); also closes removeRedefinedFeatures condition 2.
• Set C behind a flag (148 rules); will re-baseline the corpus.

Out of scope

TypeFeaturing and BindingConnector (18) — no effect on Namespace::membership.

Related

#322 (needs the same library registry),
#288 (corpus re-baselining).