Set up evals with coding agents

Set up Atlan evals for this repository's agent. Read these first:
https://platform.atlan.com/evals/quickstart.md, https://platform.atlan.com/evals/scorers.md,
https://platform.atlan.com/evals/agents.md, https://platform.atlan.com/evals/ci.md.

Tasks
1. Find the agent's entry point. Write a thin adapter
   task(input) -> {"answer": ..., "tool_calls": [{"name", "args"}]}
   (toolCalls in TypeScript). Record tool calls where the tools execute,
   not from the model's own account. Replace tools with side effects by
   recording stand-ins.
2. Create evals/cases.py with 10-30 cases covering the main behaviours and
   known failures. Each case: a stable name, input {"question": ...}, and
   expected (the answer facts and the tools that should be called).
   Push them with atlanai.push_dataset.
3. Write deterministic scorers first (required facts, tool choice, tool
   arguments). Add an LLM-judge scorer only for what code cannot decide.
4. Create evals/run.py (with an empty evals/__init__.py) that pushes the
   dataset and calls atlanai.Eval with a fixed eval name. Run it with
   `python -m evals.run`; every case must finish without an error.
   For TypeScript, create evals/run.ts with pushDataset and Eval from
   @atlanai/sdk, run it with `npx tsx evals/run.ts`, and make it pass
   `tsc --strict`.
5. Add .github/workflows/atlan-evals.yml using
   atlanai/agent-registry-action/eval, triggered on pull_request and on
   push to main, plus a requirements.txt with the agent's dependencies
   (or the TypeScript workflow from the CI page).

Rules
- Atlan Trident does not run the agent. Eval runs in this process or CI.
- Install the latest SDK: pip install -U 'atlanai[tracing]' or
  npm install @atlanai/sdk@latest. Python needs the tracing extra.
- Eval reads ATLAN_API_KEY, ATLAN_WORKSPACE_ID, and ATLAN_BASE_URL.
  AtlanClient reads nothing from the environment; pass its arguments.
- Never hardcode credentials. The workflow reads secrets.ATLAN_API_KEY and
  vars.ATLAN_WORKSPACE_ID, set in the action step's env: the action does
  not pass its api-key input to the command.
- Keep the eval name fixed. Put variants in config.
- Scorers return 0..1, higher is better, or None to abstain. Never return
  1.0 for a case a rule does not cover.
- Scorers see the case's input, expected, and metadata, and only what the
  task returns. Return tool calls from the task if scorers need them.
- Dataset records need an object input, with the question under input_key
  (default question). {"value": x} as expected reaches the scorer as x.
- Dataset names are workspace-wide. Pushing to an existing name adds to it.
- Results are create-only and finished experiments are frozen. To fix a
  run, start a new one. Do not write summary.scores yourself.
- Hosted llm_judge scorers score recorded sessions, not Eval cases. For a
  judge inside Eval, call a model from a code scorer.
- Python Eval cannot run inside an event loop. Use await async_eval(...).
- The agent version is not recorded automatically. Put it in config. In
  the CI action, Python Eval records the commit and the action's model
  input, unless config already has a git or model key.
- Hosted judges need sessions. App traffic is judgeable only after it is
  recorded as a session whose external_session_id equals the spans'
  session ID.
- The CI action reads experiments that Python Eval reports. A TypeScript
  eval must also write the results file described on the CI page.
- "reuses a Registry name with a different identity" on SDK 0.3.4 or
  earlier: upgrade. On a current SDK, the workspace already has a scorer
  with the generated name (eval name and scorer name, lowercased, joined
  by -) of a different kind, such as a hosted judge: rename the scorer or
  set registry_name (registryName in TypeScript).
- In TypeScript, compare structured values key-order-insensitively.

Stop and ask before running anything with side effects (sends email,
writes to production) that an eval run would trigger.