fix(registry): keep consumer-provider attrs under strict attribute scoping (#265)

[dmealing]

Intent

Fix GitHub #265: strict attribute scoping (FR-033 B2b applyStrictAttrScoping) wrongly pruned attributes a consumer provider added via registry.extend() to a spec-declared core subtype — blind to who registered it — forcing whole-file --lax. It was a THREE-way cross-port divergence on identical input: TypeScript accepted (correct/reference), Python + C# rejected with ERR_UNKNOWN_ATTR (the prune bug), Java/Kotlin accepted but only because the sanctioned consumer registry path skipped spec scoping entirely (a weaker strict mode — a second bug). Fix: stamp each per-type attr with its contributing provider id at registration (compose loop sets currentProviderId around each registerTypes; register/extend record (type,subType,attr)->id in a side map; unstamped/build-time defaults to a LIBRARY sentinel), and the B2b prune drops ONLY library-origin attrs so consumer extensions survive. Java also adds a RegistryManifest.composeMetamodelRegistry(extraProviders) seam so JVM consumer registries (setTypeRegistry) get provenance-safe scoping instead of skipping it; raw MetaDataRegistry.compose is unchanged. TypeScript has NO product change (it is the reference + gate lane). Java's extendType diff-stamp must diff new attr names against existing.getChildRequirements() (direct+inherited) because TypeDefinitionBuilder.from flattens inherited into the rebuilt direct tier — a subtle latent over-stamp fixed + pinned with a Java-local regression (object.projection/@Discriminator). Invariants held and verified per port: NO new error codes; the registry-conformance manifest byte-match is UNCHANGED in every port (the guard only spares consumer attrs; library-only composition is a structural no-op — the library-id set is DERIVED from the same provider list that seeds compose); the strict CHECK stays own-attrs-only (ADR-0039, untouched). Gated by 4 new fixtures in fixtures/provider-composition-conformance/compose-load/ (a NEW subdir invisible to the non-recursive un-updated runners); fixtures 1+4 span all three divergent behaviors. Verified: all 4 fixtures + registry-conformance byte-match green in TS/Python/C#/Java(+Kotlin). Went through full subagent-driven development: per-task reviews (C# fixed a Registry->Loader layering inversion; Java fixed the extendType diff-base over-stamp) + a final whole-branch review (Ready to merge: Yes). PR should Close #265. Coordinated cross-port patch (PyPI + NuGet + Maven; npm reference-only, no product change) when Doug cuts it. Accepted residuals (documented in the design non-goals + docs/features/extending-with-providers.md): the core-attr-NAME ERR_PROVIDER_ATTR_CONFLICT divergence, the B2a structural-children twin, and the convergent base-subtype behavior.

What Changed

• Stamp each per-type attribute with its contributing provider at registration; the FR-033 strict-attribute prune now drops only library-origin attrs, so attributes a consumer provider adds via registry.extend() to a spec-declared subtype survive. Closes the cross-port divergence (TS accepted; Python + C# rejected with ERR_UNKNOWN_ATTR; Java/Kotlin accepted only by skipping spec scoping entirely). In C#, LibraryProviders/LibraryProviderIds move off the Loader onto CoreTypes (fixing a Registry→Loader layering inversion).
• Java/Kotlin: add a RegistryManifest.composeMetamodelRegistry(extraProviders) seam so JVM consumer registries get provenance-safe scoping, and fix extendType's diff-base to include inherited attrs so TypeDefinitionBuilder-flattened inherited library attrs aren't mis-stamped as consumer origin.
• Add a new compose-load/ subdir of 4 cross-port conformance fixtures and extend the provider-composition suites in every port; no new error codes and the registry-conformance manifest byte-match is unchanged in all ports.

Closes #265.

Risk Assessment

✅ Low: A well-bounded, faithfully-implemented cross-port fix with a thorough design: I source-verified the load-bearing invariants (no new error codes; library-only composition stamps every attr library-origin so the B2b prune and registry-conformance manifest are byte-identical; the strict check is untouched; MetaDataTypeId is a record so the provenance lookup does not silently no-op; Java's extendType diff-base correctly uses existing.getChildRequirements() direct+inherited and is pinned by a regression test), found no correctness bug in any port, and the single finding is informational about a niche library-internal path no consumer uses.

Testing

Exercised the #265 fix across every port with focused conformance runs and two before/after bug reproductions. TS reference (11/11, test-only, no product change), Python (11/11, with a provenance-blind-prune revert showing the consumer decimals attr was wrongly pruned → ERR_UNKNOWN_ATTR pre-fix and survives post-fix), C# (11/11, registry-inspection + strict-load paths), and Java (10/10, via the new composeMetamodelRegistry seam, with a revert of the one-line extendType diff-base fix reproducing the object.projection/@Discriminator over-stamp). Verified the held invariants directly: registry-conformance manifest byte-match unchanged (Python/C#/Java 3/3 each, expected-registry.json untouched), no new error codes, raw compose() untouched, and the typo/misplaced-attr cases still reject (strict check untouched). All targeted tests pass; working tree left clean.

Evidence: Python #265 before/after (prune-bug divergence reproduction)

AFTER #265: declared view.currency attrs = ['locale','decimals']; strict-load @decimals:2 -> [] PASS; typo @decimalz -> ERR_UNKNOWN_ATTR PASS; @maxLength on field.boolean -> ERR_UNKNOWN_ATTR PASS. BEFORE #265 (provenance-blind prune reverted): declared = ['locale'] (decimals pruned); strict-load @decimals:2 -> ['ERR_UNKNOWN_ATTR'] FAIL (the reported divergence). Compose-load fixtures 1+2 fail on reverted code, 3+4 stay green — tests gate the fix.

#265 — Python port (was the PRUNE-BUG divergent port) — before/after provenance prune

End-user scenario: a consumer provider extends the spec-declared core subtype
`view.currency` with a new int attr `decimals`, then authors `view.currency @decimals:2`.
Run as: `uv run python /tmp/repro_265.py` (repro script exercises all 4 behaviors).

================ AFTER #265 (provenance-scoped prune — COMMITTED) ================
(1) declared view.currency attrs = ['locale', 'decimals']
    'decimals' (consumer) present: True   <-- consumer attr SURVIVES composition
(2) strict-load @decimals:2        -> []                             expect []                => PASS
(3) strict-load @decimalz:2 (typo) -> ['ERR_UNKNOWN_ATTR']           expect [ERR_UNKNOWN_ATTR] => PASS
(4) @maxLength on field.boolean    -> ['ERR_UNKNOWN_ATTR']           expect [ERR_UNKNOWN_ATTR] => PASS

================ BEFORE #265 (pre-fix prune, blind to provenance — TEMP REVERT) ================
(1) declared view.currency attrs = ['locale']
    'decimals' (consumer) present: False   <-- consumer attr PRUNED (the bug)
(2) strict-load @decimals:2        -> ['ERR_UNKNOWN_ATTR']           expect []                => FAIL  <-- the reported divergence
(3) strict-load @decimalz:2 (typo) -> ['ERR_UNKNOWN_ATTR']           expect [ERR_UNKNOWN_ATTR] => PASS  (still correctly rejected)
(4) @maxLength on field.boolean    -> ['ERR_UNKNOWN_ATTR']           expect [ERR_UNKNOWN_ATTR] => PASS  (still correctly rejected)

The reverted-run shows the exact divergence the intent names: Python rejected the
author's own valid consumer attr with ERR_UNKNOWN_ATTR. Compose-load conformance
fixtures 1 (registry) + 2 (strict-load) FAIL on the reverted code; 3 + 4 (no-over-widen)
stay green — proving the fixtures gate the fix, not the invariant-only cases.

Evidence: Java #265 extendType diff-base over-stamp before/after

Java-local regression InheritedAttrProvenanceRegression.extendingASubtypeDoesNotSpareItsInheritedOutOfScopeAttrs. AFTER (getChildRequirements direct+inherited): 10/10 PASS. BEFORE (getDirectChildRequirements direct-only, reverted): 9/10, regression FAILS 'expected null, but was: <optional child[name=discriminator]>' — inherited @discriminator wrongly survives on object.projection after an unrelated extendType. Bug latent for the shipped 4-fixture corpus (other 9 pass), reachable only via the composeMetamodelRegistry(extra) seam.

#265 — Java-local extendType diff-base over-stamp regression (object.projection/@discriminator)

The Java-unique fix (commit 0f67aa7b4): stampNewAttrProvenance's "already-existed"
base set walked existing.getDirectChildRequirements() (direct-only), but the
extended definition it diffs against is built by TypeDefinitionBuilder.from(existing)
which flattens existing.getChildRequirements() (direct + INHERITED) into the rebuilt
direct tier. So every previously-INHERITED library attr was seen as "new" and
stamped with the extending provider's id → a consumer extendType() of object.projection
for an unrelated reason mis-stamped object.base's inherited @discriminator as the
consumer's own, sparing it from the B2b prune (discriminator is scoped to object.entity).

Test: ProviderCompositionConformanceTest$InheritedAttrProvenanceRegression
      .extendingASubtypeDoesNotSpareItsInheritedOutOfScopeAttrs
Routes through the real composeMetamodelRegistry(extra) seam; asserts against the
registry's declared-attr lookup for (object, projection).

AFTER #265 (committed — getChildRequirements(), direct+inherited): 10/10 PASS
BEFORE #265 (temp-revert to getDirectChildRequirements(), direct-only): 9/10 PASS, the
  regression test FAILS:
    expected null, but was: <optional child[name=discriminator, type=attr.string]>
  i.e. @discriminator wrongly survived on object.projection (the over-stamp bug).
  The 4 compose-load + 5 flat tests still pass — confirming the bug is latent for the
  shipped corpus and only reachable via the seam (exactly as the commit message states).

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

⚠️ **Review** - 1 info

• ℹ️ server/java/metadata/src/main/java/com/metaobjects/registry/MetaDataRegistry.java:478 - The provenance stamp has two definition-rebuild entry points that diff asymmetrically. extendType() (line ~379) correctly diffs new attr names against existing.getChildRequirements() (direct+inherited) before stamping via stampNewAttrProvenance — so the flattened-inherited library base attrs keep library origin and stay prunable. But the data-driven concern-provider path applyExtendsAttrs() (line 478) routes through register(), whose recordAttrProvenance() blanket-stamps the rebuilt definition's ENTIRE direct-requirement set (which TypeDefinitionBuilder.from(existing) has flattened inherited attrs into) with currentProviderId. For the only current callers — the library's own ui/prompt concern providers, invoked during their own registerTypes turn — currentProviderId is a library id, so the stamp is correct and the registry-conformance manifest stays byte-identical. The gap is latent: applyProviderExtends is public, so a downstream provider that extended a spec subtype through that mechanism (rather than the sanctioned extendType()/extend() path) would mis-stamp its flattened-inherited library attrs as its own and spare them from the B2b prune — the exact over-spare class extendType's diff was added to prevent. No library flow is affected; this documents the coverage boundary of the provenance mechanism on a non-documented, library-internal API.

✅ **Test** - passed

✅ No issues found.

• cd server/typescript && bun test packages/metadata/test/provider-composition-conformance.test.ts (11 pass, 0 fail — TS reference lane)
• cd server/python && uv run pytest tests/conformance/test_provider_composition_conformance.py -v (11 passed)
• cd server/python && uv run python /tmp/repro_265.py (4/4 end-user scenarios PASS: registry holds decimals; strict-load @decimals:2 clean; typo @decimalz rejected; @maxLength on field.boolean rejected)
• Python BEFORE/AFTER: temporarily reverted spec_metamodel._apply_strict_attr_scoping prune to pre-#265 (direct-only, provenance-blind) form — repro scenarios 1+2 then FAIL (@decimals pruned -> ERR_UNKNOWN_ATTR), 3+4 stay green; restored via git checkout and re-confirmed 11 passed
• cd server/python && uv run pytest tests/conformance/test_provider_composition_conformance.py -k compose_load with buggy prune reverted -> fixtures 1+2 FAIL (proves tests gate the fix), 3+4 pass
• cd server/csharp && dotnet test MetaObjects.Conformance.Tests --filter ProviderComposition (Passed: 11, Failed: 0)
• cd server/java && mvn -pl metadata test -Dtest=ProviderCompositionConformanceTest (Tests run: 10, Failures: 0)
• Java BEFORE/AFTER: reverted stampNewAttrProvenance diff-base existing.getChildRequirements()->getDirectChildRequirements() (commit 0f67aa7b4 one-line fix) -> InheritedAttrProvenanceRegression.extendingASubtypeDoesNotSpareItsInheritedOutOfScopeAttrs FAILS (expected null but was @discriminator), other 9 pass; restored, re-confirmed 10/10
• cd server/python && uv run pytest tests/conformance/test_registry_conformance.py (3 passed — byte-match UNCHANGED)
• cd server/csharp && dotnet test MetaObjects.Conformance.Tests --filter RegistryManifestConformance (Passed: 3, Failed: 0)
• cd server/java && mvn -pl metadata test -Dtest=RegistryManifestConformanceTest (Tests run: 3, Failures: 0)
• git diff base..target -- fixtures/registry-conformance/ (empty — expected-registry.json untouched)
• git diff base..target grep for added ERR_ codes not already-existing (empty — NO new error codes)
• git diff base..target -- server/typescript/ (only the test file changed — NO TS product change)

✅ **Document** - passed

✅ No issues found.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.