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

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:

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).