Allow doctrine/annotations ^2.0 for PHP 8.2+ / modern doctrine/lexer compat

[CapturedMomentum]

Problem

In modern PHP projects (Laravel 11+, Symfony 7+, etc.), doctrine/lexer is commonly pinned to 3.x by transitive dependencies. The SDK's doctrine/annotations: ^1.9 constraint can only resolve to 1.x versions, all of which require lexer 1.x or ^1 || ^2 — and so are unreachable when lexer 3.x is locked. Composer then either:

• falls back to an older SDK tag (pre-1.27.0) that doesn't require doctrine/annotations at all, leaving JMS Serializer 3.x without an annotation reader, or
• refuses to resolve at all on stricter projects.

Either way, downstream consumers on PHP 8.2+ hit:

RuntimeException: You must define a type for Eversign\Business::$businessId.

…because the @Type docblocks go unread without doctrine/annotations installed. Reproduced in a Laravel 11 install requiring eversign/eversign-php-sdk: ^1.27.

Fix (2 lines)

1. composer.json — widen to "doctrine/annotations": "^1.9 || ^2.0". Doctrine annotations 2.x is PHP 8.0+ clean and compatible with doctrine/lexer 3.x.
2. sdk/Eversign/Client.php — guard the existing AnnotationRegistry::registerLoader('class_exists') call with method_exists since doctrine/annotations 2.x removed that method. Composer-based autoloading handles class discovery for modern setups; the call was already a backstop for very old installs (already guarded by class_exists).

What this does NOT change

• No DTO code modified
• No PHP version constraint changes
• No new dependencies
• Existing @Type / @var docblock annotations continue to work
• Upward-compatible for consumers on doctrine/annotations 1.x (the method_exists short-circuit is a no-op there)

Verified

In a Laravel 11 environment with doctrine/lexer 3.0.1 locked, the SDK now installs at 1.27.0 alongside doctrine/annotations 2.0.2, and new Eversign\Client('fake-key') constructs cleanly + reaches the live API (where it then fails on the bogus key — proving the JMS deserialization path executed to completion).