Allow pre-built instance handlers in element registration

[valeriudev]

Registering an element with a pre-built object instance as the handler throws at build time:

$foo = new Foo();
Server::builder()->addTool(handler: [$foo, 'bar'], name: 'foo')->build();
// Mcp\Exception\InvalidArgumentException: Invalid array handler format.
// Expected [ClassName::class, 'methodName'].  (HandlerResolver.php)

This is the only place that rejects an instance: the Handler type alias already declares array{0: object|string, 1: string}, getHandlerDescription() already formats object handlers, and the runtime invoker (ReferenceHandler) already dispatches them via its is_callable branch. HandlerResolver::resolve()'s guard simply required a string in slot 0, out of sync with that contract.

Fix: accept an object in slot 0 and normalize it to its class name for reflection — the same is_object($h[0]) ? $h[0]::class : $h[0] idiom getHandlerDescription() already uses. The guard can't be replaced by is_callable(), since is_callable([Class::class, 'instanceMethod']) is false and that lazy-instantiate form must keep working.

This unblocks handler objects with constructor dependencies that the container-less new $className() fallback cannot build.

Tests: added testResolvesValidInstanceArrayHandler; full unit suite, CS, and PHPStan are green.

Fixes #369

[soyuka]

is_object($handler[0]) now accepts any object, including Closure and anonymous-class instances. A handler like [$closure, 'method'] would pass this guard, then $closure::class yields Closure, and the user gets Handler method "method" not found in class "Closure" instead of the format error — which is misleading.

Two options:

• Explicitly reject Closure here (!$handler[0] instanceof \Closure) so the format-error path catches it.
• Or accept it knowingly and document that [$closure, 'method'] is undefined behavior.

Also: the 4-clause negated condition is hard to scan. Consider extracting $isHandler = \is_string($handler[0]) || \is_object($handler[0]) or splitting into early returns.

[soyuka]

Pre-existing nit surfaced while reviewing this PR: at L78, the error message reads 'Handler method "%s::%s" must be abstract.' but the branch rejects abstract methods — it should read must not be abstract. Worth a follow-up commit while this file is open.

[soyuka]

Suggested change

* Allow registering an element handler as a pre-built object instance (`[$instance, 'methodName']`) via `Builder::addTool()`, `addResource()`, `addResourceTemplate()`, and `addPrompt()`. `HandlerResolver` previously rejected instances with "Invalid array handler format" even though the `Handler` type already permitted them — this unblocks handler objects with constructor dependencies that the container-less fallback cannot build.

* Allow `[$instance, 'methodName']` as an element handler in `Builder::addTool()`, `addResource()`, `addResourceTemplate()`, and `addPrompt()`. Unblocks handlers with constructor dependencies that the container-less `new $className()` fallback cannot build.