chore(security): bump langchain-core to 1.6.1, rebased on main

[cdbartholomew]

Supersedes #11. Same intent — close the langchain-core advisories including the critical GHSA-c67j-w6g6-q2cm (serialization injection enabling secret exfiltration) — but regenerated on top of main after #10 merged.

Why #11 could not be merged as-is

#11 branched before #10, so its lockfile predates those fixes. Merging it would have rolled three of them back:

package	main (after #10)	#11 head
urllib3	2.7.0	2.3.0	⚠️ regression
requests	2.34.2	2.32.3	⚠️ regression
orjson	3.12.0	3.10.15	⚠️ regression
pytest	9.1.1	8.3.5	regression (dev-only)
h11	0.16.0	0.16.0	unaffected

The h11 critical would have survived — both branches landed on 0.16.0 — but the other three would silently have gone backwards. A lockfile cannot be rebased by replaying commits; it has to be regenerated.

This change

uv lock --upgrade-package langchain-core against current main. The manifest declares langchain-core>=0.3.45, so no manifest edit was needed.

anyio              4.8.0    -> 4.15.0
langchain-core     0.3.45   -> 1.6.1
langsmith          0.3.15   -> 0.12.1
typing-extensions  4.12.2   -> 4.16.0

No regressions — h11 0.16.0, urllib3 2.7.0, requests 2.34.2 and orjson 3.12.0 all stay where #10 put them. Verified by parsing both lockfiles and diffing resolved versions rather than reading the patch.

Verifying a v0 → v1 major without usable tests

Both tests in this repository require live API access, so they cannot exercise this change. In CI they fail at setup with ApiException: (402) — "API access is available on paid plans only"; locally they fail on a missing VECTORIZE_TOKEN.

That is worth fixing on its own: as it stands, no PR in this repo can be validated by CI, which is likely why these have sat since Sep 2.

What was checked directly instead:

• uv sync --frozen --all-groups clean
• every langchain_core symbol the integration imports at runtime resolves under 1.6.1 — Document, BaseRetriever, CallbackManagerForRetrieverRun, RunnableConfig
• langchain_vectorize imports, and VectorizeRetriever still has BaseRetriever in its MRO
• the v1 BaseRetriever._get_relevant_documents signature still matches the override in retrievers.py, and the pydantic model still resolves its 10 fields

The v0 → v1 boundary did not move any API this integration depends on.

[cdbartholomew]

Closing — superseded by #11, now merged.

#11 carries the identical lockfile. I opened this one under my own account, which made it unapprovable by me and would have needed a third reviewer; putting the fix on the original branch instead kept the author/reviewer split intact.