Feature Request: Support user identity/credentials for VertexAISearch grounding

Thanks for stopping by to let us know something could be better!

**PLEASE READ**: If you have a support contract with Google, please create an issue in the [support console](https://cloud.google.com/support/) instead of filing on GitHub. This will ensure a timely response.

**Is your feature request related to a problem? Please describe.**

When using `VertexAISearch` for grounding with ACL-protected datastores or third-party connectors (e.g., Confluence, SharePoint), the current implementation only uses the application's service account credentials. This prevents proper access control based on the end user's identity, which is critical for enterprise applications where users should only see data they're authorized to access.

This is blocking production deployments for applications using the Agent Development Kit (ADK), as documented in https://github.com/google/adk-python/issues/897 (8+ users affected).

**Describe the solution you'd like**

Add support for user identity/credentials to the `VertexAISearch` type, similar to how other authenticated tools work. The current `VertexAISearch` dataclass only supports:

```python
class VertexAISearch:
datastore: Optional[str]
engine: Optional[str]
data_store_specs: Optional[list[VertexAISearchDataStoreSpec]]
filter: Optional[str]
max_results: Optional[int]
```

None of these allow passing user identity for ACL enforcement. We'd like to see support for user credentials, such as:

```python
class VertexAISearch:
# ... existing fields ...
user_pseudo_id: Optional[str] = None
# or whatever parameter the backend Vertex AI Search API supports
```

**Key question**: Does the underlying Vertex AI Search/Discovery Engine API support passing user identity in grounding requests? If yes, please expose it in the SDK. If not, please escalate this to the Vertex AI Search product team.

**Describe alternatives you've considered**

1. **Using the `filter` parameter**: This only works for custom metadata-based ACLs that we manage ourselves. It doesn't work with third-party connectors (Confluence, SharePoint) that have their own external ACL systems.

2. **Building custom tools instead of using built-in grounding**: Requires significantly more development effort and loses the benefits of model-integrated grounding.

3. **Granting the service account broad permissions**: This violates the principle of least privilege and cannot enforce user-level access control.

**Additional context**

**Use cases this blocks:**
- Vertex AI Search with [Confluence connector](https://cloud.google.com/agentspace/docs/connect-confluence-cloud) where ACLs are enforced
- Document-level access control in enterprise knowledge bases
- Any scenario requiring end-user impersonation for search

**Related resources:**
- Blocked issue: https://github.com/google/adk-python/issues/897
- [Vertex AI Search ACL docs](https://cloud.google.com/generative-ai-app-builder/docs/data-source-access-control)
- [ADK authentication framework](https://google.github.io/adk-docs/tools/authentication/) (which can't be used until SDK supports this)

The ADK already has infrastructure to handle user authentication for other tools (`BaseAuthenticatedTool`), but cannot integrate it with `VertexAiSearchTool` because the underlying `google-genai` SDK doesn't expose user identity parameters.