fix(session_search): a bare session id never reads another profile's state.db

Reading a session by id that missed the caller's store fell through to
_locate_session_db(), which opened every profile's state.db read-only and
returned the first owner's full transcript — no opt-in, no profile named, and
the miss path even fired after an explicit non-matching profile= read. Any
caller holding an id (ids appear in logs and tool output) could read a
foreign profile's conversation. Profiles are isolated islands by design.

A miss now stays a miss, with a hint to name the owning profile
(profile=<name> / @session:<profile>/<id>), which remains the sanctioned,
explicit cross-profile read. The schema eval runner no longer needs to fake
the scan.

Reported by the #106761 filer; reproduced by @kokhlo. Refs #87779.

evals/session_search_schema/runner.py

@@ -85,21 +85,7 @@ def load_arm(path: Path, name: str, work_db_path: Path):
             return SessionDB(db_path=work_db_path, read_only=True)
         raise ValueError(f"profile '{profile}' does not exist")
 
-    def _fake_locate_session_db(session_id):
-        try:
-            db = SessionDB(db_path=work_db_path, read_only=True)
-            row = db._conn.execute(
-                "SELECT 1 FROM sessions WHERE id = ?", (session_id,)
-            ).fetchone()
-            if row:
-                return db, "work"
-            db.close()
-        except Exception:
-            pass
-        return None, None
-
     mod._resolve_profile_db = _fake_resolve_profile_db
-    mod._locate_session_db = _fake_locate_session_db
     return mod