docs: warn about read_cell stale-output lag in jupyter-mcp guidance

[KadenMc]

Summary

• Adds a warning to the vendored AGENTS.md "Working with Jupyter MCP" section: read_cell / read_notebook outputs lag live kernel state after execute_cell. Cached output and execution count may still reflect the prior run.
• Mitigation in the same bullet: trust execute_cell's return value to verify the most-recent execution, don't round-trip through read_cell.
• Sits next to the existing notebook_run-all-cells 404 warning — both are "tool exists but has a footgun" notes in the same family.

Why

Discovered while smoke-testing the aexp install --with-jupyter integration end-to-end in a downstream consumer (electricrag). The agent's report:

read_cell — Works, but cached output lags live state — showed x = 1024 while execute_cell had just returned the new python 3.12 … output. The execution count was also stale by 1. Worth knowing: don't rely on read_cell outputs to verify the most-recent run; trust the execute_cell return value instead.

Without this note, a fresh agent that reaches for read_cell to confirm an execution will silently get stale data and act on it.

Scope

Documentation only. No tool/code changes. The underlying caching behavior is upstream (`jupyter-mcp-server`); a tighter fix would belong there but this warning gets agents unblocked immediately.

Test plan

• Verify the new bullet renders well in the AGENTS.md flow (no list-formatting break)
• Confirm the placement reads naturally next to the `notebook_run-all-cells` warning

🤖 Generated with Claude Code