INTPYTHON-1066 Make the minimum-dependency-version CI step actually test minimum versions (#433)

[INTPYTHON-1066](https://jira.mongodb.org/browse/INTPYTHON-1066)

> [!WARNING]
> **Do not merge until
[#431](https://github.com/langchain-ai/langchain-mongodb/pull/431) and
[#432](https://github.com/langchain-ai/langchain-mongodb/pull/432) have
landed, plus the deepagents-vfs floor fixes.** This PR turns on a test
that has never run, and `check_diff.py` runs every lib when `.github`
changes. Opened as a draft for that reason.

## Summary

The "Run unit tests with minimum dependency versions" step in both
`_test.yml` and `_release.yml` does not test minimum dependency
versions. It never has, in any of the four libs.

```yaml
uv sync --python=... --resolution=lowest-direct
just unit_tests
```

Every `just` test recipe is `uv run pytest`, and `uv run` re-syncs the
environment from the lockfile. Because the lockfile was written under a
different resolution mode, it discards the `lowest-direct` install
entirely before pytest starts. uv states this outright in the log:

```
Ignoring existing lockfile due to change in resolution mode: `lowest-direct` vs. `highest`
```

Measured in `langchain-mongodb-deepagents-vfs` on Python 3.11:

| Package | Installed by the `lowest-direct` sync | What pytest actually
ran against |
|---|---|---|
| deepagents | 0.6.0 | 0.7.8 |
| tiktoken | 0.8.0 | 0.14.0 |
| pydantic | 2.13.0 | 2.13.4 |
| wcmatch | 10.1 | 11.0.1 |

So the step has been running the same highest-version suite twice, in
both the PR and release workflows. This is why the recent Python 3.14
floor problems went unnoticed — the one job designed to catch that class
of bug was inert.

## Changes in this PR

- Call `pytest` directly with `--no-sync` instead of going through `just
unit_tests`. The recipe hardcodes `uv run`, so `--no-sync` cannot be
injected through it without changing all four justfiles; the test path
(`tests/unit_tests`) is identical across every lib.
- Print `uv pip list` before the run, so the resolved versions are
auditable from the CI log. A silent regression of this kind is exactly
what happened here, and a visible version list makes it a one-glance
check.
- A comment on both steps explaining why `just` is bypassed, so nobody
"tidies" it back.

## Test Plan

Turning this step on exposes real breakage that was previously hidden,
so all four libs were verified at true minimum versions on Python 3.11
before opening this — using `uv sync --resolution=lowest-direct`
followed by `uv run --no-sync pytest`, with resolved versions checked on
every run:

| Lib | Result at minimum versions | Status |
|---|---|---|
| `langchain-mongodb` | 75 passed | needs #432 — fails on `main` today
(12 `test_cache.py` failures, then 5 collection errors) |
| `langchain-mongodb-deepagents-vfs` | 131 passed, 0 skipped | needs the
floor commit on `fix/pydantic-langchain-py314` — on `main` today it is
`INTERNALERROR`, 0 tests collected |
| `langgraph-checkpoint-mongodb` | 17 passed | clean on `main`, no
change needed |
| `langgraph-store-mongodb` | 23 passed | clean on `main`, no change
needed |

The two langgraph libs were run against a live local MongoDB, matching
what CI provides.

## Merge order

1. #431 (pydantic floor) and #432 (langchain-mongodb floors)
2. deepagents-vfs floor fixes (`tiktoken`, `pytest-asyncio`,
`mongomock`)
3. **this PR**

## Follow-up (out of scope)

Consider a companion check that installs **only runtime dependencies**
at their floors. This step installs the default `dev` group too, so a
hard-pinned dev dependency can clamp a runtime dependency above its
declared floor and hide that the floor is untested — which is exactly
what `langchain-tests==1.1.9` was doing to `langchain-core>=1.2.5` (see
#432).

## Checklist

### Checklist for Author

- [ ] Did you update the changelog (if necessary)?
- [ ] Is the intention of the code captured in relevant tests?
- [ ] If there are new TODOs, has a related JIRA ticket been created?
- [ ] Has a MongoDB Employee run [the patch build of this
PR](https://github.com/mongodb-labs/ai-ml-pipeline-testing?tab=readme-ov-file#running-a-patch-build-of-a-given-pr)?

### Checklist for Reviewer

- [ ] Does the title of the PR reference a JIRA Ticket?
- [ ] Do you fully understand the implementation? (Would you be
comfortable explaining how this code works to someone else?)
- [ ] Is all relevant documentation (README or docstring) updated?

Signed-off-by: Casey Clements <casey.clements@mongodb.com>
Co-authored-by: Steven Silvester <steve.silvester@mongodb.com>