INTPYTHON-1065 Raise langchain-mongodb dependency floors for Python 3.14 (#432)

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

## Summary

Three dependency floors in `libs/langchain-mongodb/pyproject.toml` are
too low. One blocks installation on Python 3.14; the other two break the
unit suite at declared minimum versions.

None were caught by CI, because the job designed to catch exactly this —
"Run unit tests with minimum dependency versions" — is a no-op. Every
`just` recipe is `uv run pytest`, and `uv run` re-syncs from the
lockfile, discarding the `lowest-direct` install before pytest starts.
uv says so explicitly: `Ignoring existing lockfile due to change in
resolution mode: lowest-direct vs. highest`. That fix is tracked
separately and must land **after** this one, since it touches `.github`
and therefore tests all four libs at once.

**1. `numpy>=1.26`** — on Python 3.14, `lowest-direct` selects
`numpy==2.1.0`, which ships no cp314 wheel. uv falls back to a source
build that fails to compile (`string_fastsearch.h: error: no type named
...`). numpy 2.3.2 is the first release with cp314 wheels.

**2. `langchain-core>=1.2.5`** — at minimum versions, 12 tests in
`test_cache.py` fail with `AttributeError: 'FakeLLM' object has no
attribute 'asdict'`. `test_cache.py` calls `llm.asdict()` at lines 103
and 212; that method landed in langchain-core 1.4.2 (bisected).

**3. `typing-extensions>=4.12.2`** — 5 test modules fail at collection
with:
```
TypeError: _TypedDictMeta.__new__() got an unexpected keyword argument 'extra_items'
  langchain_protocol/protocol.py:22
```
`langchain-protocol` (pulled in via `langchain-core`) uses PEP 728
`TypedDict extra_items`, added in typing-extensions **4.13.0**, but
declares only `typing-extensions>=4.7.0`. Because typing-extensions is a
direct dev dependency here, `lowest-direct` pinned it to exactly 4.12.2.
Our floor has to carry the upstream under-declaration.

> [!NOTE]
> Failure 3 is **pre-existing on `main`**, not introduced by this PR.
Verified two ways: reverting the langchain-core change does not fix it,
and a pristine `main` worktree fails identically at `lowest-direct`.

> [!IMPORTANT]
> **This PR is necessary but not sufficient for Python 3.14.** Fixing
numpy uncovers a second build failure underneath —
`pydantic-core==2.33.2`, via `langchain-classic` 1.0.0 → `pydantic`
2.11.10 — resolved by the `pydantic>=2.13.0` floor in #431. Verified
that both together give a clean `uv sync --resolution=lowest-direct
--python=3.14` (106 packages, no build step). **Both PRs must be on
`main` before langchain-mongodb can claim 3.14 support.**

## Changes in this PR

- **`numpy` split by environment marker** rather than bumped flat:
  ```toml
  "numpy>=1.26; python_version < '3.14'",
  "numpy>=2.3.2; python_version >= '3.14'",
  ```
A flat `>=2.3.2` installs fine everywhere (numpy 2.3.2 supports
`>=3.11`, matching our `requires-python`), so this is not a correctness
question — it is about not over-constraining. numpy 1.x→2.x is an ABI
break, and anything in a user's environment compiled against the numpy 1
ABI forces `numpy<2`. A flat bump would make this package uninstallable
for those users on 3.11–3.13, Python versions where nothing about numpy
2 is required.

- **`langchain-core` raised to `>=1.4.2` in the runtime dependencies**,
not only the dev group. The declared 1.2.5 floor was already unreachable
and had never been tested by anything: `langchain-tests==1.1.9` is
hard-pinned in the `dev` group (a uv default group) and itself requires
`langchain-core>=1.4.0`, so no dev or CI environment can resolve below
1.4.0 — the minimum-version job was installing 1.4.0, not 1.2.5. Since
users installing from PyPI get no dev group, `>=1.2.5` was an untested
claim made to them. Raising the runtime floor makes the declared range
honest rather than aspirational.

- **`typing-extensions` raised to `>=4.13.0`** (dev group).

- `uv.lock` regenerated. No package pins changed; the diff is the
specifier updates plus the resolution-marker split the numpy marker
necessitates.

## Test Plan

Because the CI minimum-version step is inert, all minimum-version
results below were obtained locally with `uv sync
--resolution=lowest-direct` followed by `uv run --no-sync pytest`
(`--no-sync` being what prevents the re-resolution), verifying resolved
versions on each run.

- **Minimum versions, Python 3.11:** 75 passed — was 5 collection
errors, and 12 `test_cache.py` failures before that.
- **Normal resolution:** 75 passed.
- **Python 3.14 `lowest-direct` sync:** succeeds when combined with
#431's pydantic floor; fails without this PR's numpy fix, and fails
without #431.
- No source changes — dependency metadata and lockfile only.

One caveat for the reviewer: `typing-extensions>=4.13.0` was verified to
collect cleanly, but the full suite actually ran against 4.14.1, since
something else in the graph pulls it above the floor. 4.13.0 itself is
therefore not exercised by `lowest-direct`. This matters less than it
would for a runtime dependency — typing-extensions is dev-group only and
never reaches users — but the floor is documentation of the real
requirement rather than a tested constraint.

## Follow-ups (out of scope)

- Add a resolution check that installs **only** runtime dependencies at
their floors, so declared runtime floors are verified independently of
whatever the dev group clamps.
- Reconsider `langchain-tests==1.1.9`. The hard pin is local to this
repo — `langchain-postgres`, `langchain-google` and `langchain-aws` all
use ranges — and it propagates its transitive requirements as hard
floors into every resolution, which is what made `langchain-core>=1.2.5`
unreachable.

## 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>