[Capability] Make CompletionProvider's providerClass usable

[chr-hertel]

Two bugs made #[CompletionProvider(providerClass: Foo::class)] impossible to use:

• The constructor's exactly-one-source check was array_filter([$provider, $values, $enum]) — $providerClass was never counted, so the form always threw Only one of provider, values, or enum can be set. during newInstance(). Discovery catches that and drops the element, so the whole prompt/template silently disappeared.
• Discoverer::getCompletionProviders() then stored $attributeInstance->provider in the providerClass branch — always null there. (ReflectedElementLoader already had this right.)

Both are covered by a new integration test that drives a real client against a real server over stdio. The fixture's provider takes a scalar the auto-wiring container cannot supply, so it can only come from Container::set() — completions arriving at all prove the attribute reached the registry and the container was asked to build it.

Verified the test actually catches both bugs: with neither fix the prompt is missing entirely (Prompt not found: "book_seat"), with only the constructor fixed the completions come back empty.

Note that provider: already accepts a class-string<ProviderInterface> and resolves it the same way, so providerClass is a redundant spelling — worth a follow-up on whether to deprecate one of them. This PR only stops the advertised parameter from throwing.

Found by Copilot's review on #492.