refactor(llm): unify invoke/ainvoke dispatch across providers

[matteomedioli]

Description

Refactors LLMBase.invoke/ainvoke from an abstract dispatcher every subclass had to reimplement into a concrete dispatcher: it branches on input type (str vs list[LLMMessage]) and delegates to four narrow abstract hooks (_invoke_v1, _invoke_v2, _ainvoke_v1, _ainvoke_v2). All eight providers (AnthropicLLM, OpenAILLM, GeminiLLM, CohereLLM, MistralAILLM, OllamaLLM, BedrockLLM, VertexAILLM) migrated onto this contract, each now sharing one request builder and response parser per input version, plus a pair of _call_sync/_call_async transport hooks that differ only in whether the SDK call is awaited. This removes the duplicated sync/async dispatch and request/response logic that previously lived four times per provider.

Along the way, this fixes bugs the duplication had let drift out of sync:

• BedrockLLM now inherits from LLMBase (previously LLMInterface/LLMInterfaceV2 directly), aligning its hierarchy with every other provider. Its async path no longer stacks a sync-side rate-limit retry inside the thread-pool-executed call on top of its own async retry layer.
• OllamaLLM's async path now spreads model_params into the client.chat call the same way the sync path always did, instead of passing it verbatim as the options value — this fixed a double-nested options bug when model_params carried a sibling key (e.g. {"options": {...}, "format": "json"}).
• CohereLLM's v2 error paths now raise LLMGenerationError(e) from e consistently, preserving the original SDK exception (previously a generic "Error calling cohere" message on v2 only).

Breaking (targets 2.0): a subclass overriding invoke/ainvoke directly (a supported extension point for BaseAnthropicLLM/BaseOpenAILLM/BaseGeminiLLM) must migrate to overriding the four hooks instead. The public invoke/ainvoke/invoke_with_tools/ainvoke_with_tools calling contract for callers is unchanged.

Note: GeminiLLM's usage-tracking fix (response.usage_metadata -> LLMResponse.usage) landed separately in #621 and is already on main; this branch is rebased on top of it, not re-introducing it.

Type of Change

• Refactoring (no functional changes) — plus incidental bug fixes surfaced by the consolidation (see above)

Complexity

Complexity: Medium

How Has This Been Tested?

• Unit tests

Checklist

The following requirements should have been met (depending on the changes in the branch):

• Documentation has been updated
• Unit tests have been updated
• E2E tests have been updated
• Examples have been updated
• New files have copyright header
• CLA (https://neo4j.com/developer/cla/) has been signed
• CHANGELOG.md updated if appropriate