[Capability] Remove CompletionProvider's dead providerClass argument

[chr-hertel]

#[CompletionProvider(providerClass: Foo::class)] has never worked in any release. 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.

So rather than making it work: provider: already accepts a class-string<ProviderInterface> and resolves it through the container identically, which makes providerClass a redundant spelling that nothing can depend on — every version that shipped it threw on construction. Removing it also unlocks the positional form #[CompletionProvider(Foo::class)], which until now hit providerClass and threw.

[BC Break] in the changelog, though the practical risk is nil: no working code could have set the property.

Covered from both ends. DiscoveryTest pins the positional class-string surviving discovery unresolved, and a new integration test 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(), and completions arriving at all prove the container was asked to build it.

Found by Copilot's review on #492.