use_thread_id_as_session_id: _find_session_by_thread_id still runs the O(n) list_sessions scan

## Summary

`use_thread_id_as_session_id=True` gives `SessionManager.get_or_create_session` an O(1) direct-lookup path — but `SessionManager._find_session_by_thread_id` has **no flag branch**: it always runs the O(n) `list_sessions` scan over all the user's sessions, matching `_ag_ui_thread_id` in each session's state.

`ADKAgent.run` calls `_find_session_by_thread_id` once per `(thread, user)` per process to hydrate the multi-instance session cache, so the scan still fires for every fresh chat and every cold thread — even with the flag on.

## Measured impact (ag-ui-adk 0.6.5 + `VertexAiSessionService`, Cloud Run)

Each `list_sessions` scan against Vertex AI Agent Engine costs ~0.4–0.9s (API processing time), paid inside the user's turn before the first model call. With the flag-aware direct lookup below, our request→run-start segment dropped from ~1.1s to ~0.28s.

## Suggested fix

The lookup should honor the flag (this is what we ship as a local monkey-patch today):

```python
async def _find_session_by_thread_id(self, app_name, user_id, thread_id):
if self._use_thread_id_as_session_id:
return await self.get_session(thread_id, app_name, user_id)
# ... existing list_sessions scan for the legacy id-mapping mode ...
```

With the flag on, the thread id IS the session id, so a direct `get_session` (None when absent) is both correct and O(1); the scan remains the right recovery path only for the legacy mode where the backend generates session ids.