Conformance gap: provider-composition error codes (ERR_PROVIDER_* / ERR_REGISTRY_SEALED) need a provider-composition conformance harness

[dmealing]

Context

The FR-033 unit-test → conformance survey found four registry/provider error codes that are cross-port Tier-1 invariants (asserted in TS/Java/Python/C# unit tests with the same codes) but are not gated by any shared conformance corpus:

Error code	Trigger	Tested in
ERR_PROVIDER_DUPLICATE_ID	two providers declare the same id	TS, Java, Python, C#
ERR_PROVIDER_MISSING_DEPENDENCY	provider depends on a non-existent id	TS, Java, Python, C#
ERR_PROVIDER_DEPENDENCY_CYCLE	provider dependency cycle	TS, Java, Python, C#
ERR_PROVIDER_ATTR_CONFLICT	per-type attr collides with a common attr	TS, Java, Python, C#
ERR_REGISTRY_SEALED	mutate a sealed registry (ADR-0023)	TS, Python, C#

Why they don't fit the existing corpus

The shared fixtures/conformance/error-* corpus is metadata-input → error: each fixture is a meta.*.json document the loader must reject. These provider/registry errors are registry-composition-API behaviors — they're triggered by how providers are composed/sealed, not by a metadata document. There's no input file that expresses "two providers with a duplicate id."

Proposal

Add a small provider-composition conformance harness — a manifest format like:

{ "providers": ["duplicate-x", "duplicate-x-clone"], "expectedError": "ERR_PROVIDER_DUPLICATE_ID" }

…driven by a shared set of named test providers each port already has in its conformance adapter (e.g. TS test/conformance/adapter.ts has duplicateXProvider, cycleAProvider, etc.). Each port's runner composes the named providers and asserts the error code. This would gate the codes above cross-port without bending the metadata-input corpus.

Effort: MEDIUM (new harness + per-port runner + shared named-provider set). Not a quick fixture add — hence a tracked issue rather than inline work.

Surfaced by the FR-033 wrap-up survey (PRs #30, #31).