ServiceRedefinitionException

Thrown when a service id is registered a second time with a DIFFERENT service. Registering the same service again is a no-op and never reaches here — measured on a real boot, where the only two duplicate registrations in 96 are the same instance registered twice. ## Why this fails instead of overwriting The container used to keep the last registration and say nothing. That is not a permissive multiplicity policy, it is the absence of one: `get()` returned whoever arrived last, and the provider that lost never existed as far as any report was concerned. Nothing in this framework decides how many providers a capability admits ({@see \Milpa\Services\CapabilityMatcher}, ADR-0037): multiplicity could legitimately mean an error, a collection, an explicit replacement, a composition, or a later selection. This exception does NOT decide which — it refuses only the one option that is dishonest under every reading: > When cardinality is undefined, keeping both facts or failing is honest. Silently substituting > one for the other is not, because it destroys the evidence a decision would need. So this is a fail-closed placeholder, not a verdict that duplicates are invalid. When the framework grows a real cardinality policy, this is the seam that policy replaces. ## What it carries The four facts a reader needs and a silent overwrite threw away: the id, the service already registered, the one arriving, and where each came from.

public static function of(string $id, string $existing, string $incoming, string $from, string $to): self

Builds the refusal, naming all four facts.

Parameters