1.89.1 ships pydantic/pydantic-ai#5275 (restored `wrap_validation_errors`
on `ToolManager.handle_call`). Pinning the floor there so harness users
on the broken 1.86–1.89.0 window get a clean resolver error instead of
a runtime `TypeError: ToolManager.handle_call() got an unexpected
keyword argument 'wrap_validation_errors'`.

`uv.lock` is unchanged: `tool.uv.sources` already pulls pydantic-ai-slim
from `main`, which is past 1.89.1.

…ce; cover approved-tool ApprovalRequired re-raise (#223)

* test(code_mode): cover approved-tool re-raising `ApprovalRequired`

pydantic/pydantic-ai#5275 documents on `_resolve_single_deferred` that a
re-raised `CallDeferred` / `ApprovalRequired` from the post-approval tool
body bubbles up without re-invoking the handler. The harness's existing
`except (CallDeferred, ApprovalRequired)` clause then converts it to a
`UserError` → `MontyRuntimeError` → `ModelRetry`. Lock that contract in
with a regression test so we notice if the upstream behavior shifts.

Refresh `uv.lock` to pick up #5275 from pydantic-ai main, which restored
`wrap_validation_errors` on `ToolManager.handle_call`. No harness code
change is needed — the existing call site already uses the kwarg.

* ci: add `compat-test.yml` reusable workflow for pydantic-ai → harness compat checks

Called from pydantic-ai's CI (via `workflow_call`) to verify that an arbitrary
pydantic-ai ref doesn't break the harness's lint / typecheck / test suite. The
workflow:

- checks out harness@main and pydantic-ai @ the input ref (with optional
  `pydantic-ai-repo` for fork PRs)
- rewrites `[tool.uv.sources]` to point `pydantic-ai-slim` at the local
  checkout, then `uv lock --upgrade-package` to refresh the lock
- runs `ruff format --check`, `ruff check`, `pyright`, `pytest`

Runs without secrets and with `contents: read` only — safe to invoke from
fork-PR contexts (the calling pydantic-ai workflow gates fork PRs behind an
approval label before invoking, as defense-in-depth).

* chore: bump `pydantic-ai-slim` floor to `>=1.89.1`

1.89.1 ships pydantic/pydantic-ai#5275 (restored `wrap_validation_errors`
on `ToolManager.handle_call`). Pinning the floor there so harness users
on the broken 1.86–1.89.0 window get a clean resolver error instead of
a runtime `TypeError: ToolManager.handle_call() got an unexpected
keyword argument 'wrap_validation_errors'`.

`uv.lock` is unchanged: `tool.uv.sources` already pulls pydantic-ai-slim
from `main`, which is past 1.89.1.

* ci: bump `test-floor` pin to match new `>=1.89.1` floor

Companion to ae9428e: that commit bumped the floor in `pyproject.toml` but
left this job pinning 1.80.0, which (a) no longer matches the documented
floor and (b) would have started failing because 1.80.0 predates #5275 and
the harness's existing `handle_call(wrap_validation_errors=...)` call site
would TypeError against it.

* ci+chore: drop `[tool.uv.sources]` for pydantic-ai-slim; auto-floor `test-floor`; simplify compat-test

- Drop `[tool.uv.sources]` git override for pydantic-ai-slim so the lock
  resolves from PyPI like users would. The harness's `test` matrix and
  install path now mirror what users actually get; bleeding-edge compat
  with pydantic-ai's main is verified by pydantic-ai's `harness compat`
  job (called from its CI on PRs, main pushes, and tags). `uv.lock`
  refreshed.

- Refactor `test-floor` to read the floor version from `pyproject.toml`
  at runtime instead of hardcoding it. Bumping the floor in pyproject is
  now the single source of truth — no separate CI pin to keep in sync.

- Simplify `compat-test.yml`: with no `[tool.uv.sources]` to fight, the
  workflow just `uv sync`s the lock then `uv pip install --no-deps -e`'s
  the local pydantic-ai checkout. Same pattern test-floor uses, just
  pointing at a path instead of a PyPI version.

* ci: switch `test-floor` to `uv sync --resolution lowest-direct`; install `pydantic-graph` from checkout in compat-test

- Replace the bespoke "read floor from pyproject + pin slim only" Python
  script in `test-floor` with `uv sync --resolution lowest-direct`,
  matching pydantic-ai's `test-lowest-versions` job. Resolves *all* direct
  deps to their floors so the job exercises the full claimed compatibility
  envelope, not just slim's floor.

- Add explicit floors for the previously-unfloored dev deps so
  `lowest-direct` doesn't drag pre-Python-3 versions: `pytest>=9.0.0`,
  `anyio[trio]>=4.11.0` (where the pytest plugin started registering the
  `anyio_mode` ini option), `coverage>=7.10.7`. Match pydantic-ai's
  discipline. `pytest-anyio` has only 0.0.0 on PyPI so no floor.

- `compat-test.yml` now also `uv pip install -e`'s `pydantic-graph` from
  the local pydantic-ai checkout alongside slim. The two are sibling
  packages that version-track together; testing slim from-source against a
  PyPI `pydantic-graph` would mask cross-package issues (e.g. a slim PR
  depending on an unreleased graph change).