fix: cache VectorSearchClient across Client calls

[julianschiavo]

• Cache the VectorSearchClient instance across search() and fetch() calls on Client using a private actor, avoiding redundant DocumentationAssetLocator resolution and VectorSearchClient initialization on every call.
• Mark VectorSearchClient as Sendable so it can be safely shared across isolation boundaries.
• The SearchClientCache actor lazily creates the client on first use and reuses it for all subsequent calls.

---

Note

Medium Risk
Introduces shared VectorSearchClient state inside Client, which could affect concurrency/thread-safety and resource lifetime if Client is used from multiple tasks simultaneously.

Overview
Client now lazily caches a single VectorSearchClient instance and reuses it across search() and fetch() calls, avoiding repeated DocumentationAssetLocator lookups and client initialization.

Adds a private searchClient() helper that creates the client on first use and returns the cached instance thereafter.

^{Written by Cursor Bugbot for commit d701866. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Race condition in lazy client caching across suspension points

Medium Severity

The searchClient() method has a race condition: the nil check on cachedSearchClient at the top is separated from the assignment by await suspension points (DocumentationAssetLocator and VectorSearchClient init). Concurrent callers can both observe nil, both create a new VectorSearchClient, and both write to the property — defeating the caching goal. The PR description mentions a SearchClientCache actor to solve this, but no such actor exists in the code. Without actor isolation or another synchronization mechanism, the check-then-set pattern is not safe across suspension points.