chore(deps): aggregate envs dependabot updates

[burtenshaw]

Aggregates current Dependabot updates that only touch env packages.

Included single PRs:

• chore(deps): bump joserfc from 1.6.5 to 1.6.7 in /envs/julia_env #886 joserfc 1.6.5 -> 1.6.7 in /envs/julia_env
• chore(deps): bump joserfc from 1.6.4 to 1.6.7 in /envs/jupyter_env #889 joserfc 1.6.4 -> 1.6.7 in /envs/jupyter_env

Validation:

• uv lock --check in envs/julia_env
• uv lock --check in envs/jupyter_env
• git diff --check hf/main...HEAD

[bot-ci-comment]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[cursor]

Alignment Review Report

Automated Checks

• Lint: N/A (deferred to CI). .claude/hooks/lint.sh only lints Python (src/, tests/, envs/) and this PR changes only two uv.lock files, so there is nothing for it to lint. (The hook also can't execute in this review VM because uv isn't installed.)
• Debug code: CLEAN. .claude/hooks/check-debug.sh hits are all pre-existing files under src/ (mcp_client.py, generic_client.py, containers/test_local_docker_provider.py, …), none of which are touched by this PR.

Open RFCs Context

RFCs 000/001/002/003/005 are In Review, 010 is Draft, 004 has no status header. None concern dependency management, lockfiles, or package-index sources, so none are relevant to this change.

Scope of the diff

The PR is described as a joserfc dependabot bump, but each lockfile actually carries two distinct changes:

1. Intended — joserfc bump: julia_env 1.6.5→1.6.7, jupyter_env 1.6.4→1.6.7 (4 lines each).
2. Unintended side-effect — a full re-lock that (a) bumps the lockfile schema revision = 2 → 3 and (b) rewrites the resolver index for every package from pypi.registries.huggingface.tech → pypi.org/simple (128 entries in julia_env, 132 in jupyter_env). This accounts for ~256/260 and ~264/268 of the changed lines.

Tier 1: Fixes Required

None.

The joserfc bump itself is correct and verified:

• Transitive dep (via openenv → authlib → joserfc; no pin in either pyproject.toml) → a lock-only change is the right shape.
• 1.6.7 hashes match PyPI and are not yanked — wheel sha256 9e51e4a6…92fbe05 (70603 B), sdist sha256 6999fe89…46479fd7 (232158 B).
• Security fix: 1.6.4/1.6.5 are affected by CVE-2026-48990 / GHSA-wphv-vfrh-23q5 (RFC7797 b64=false JWS payloads bypass max_payload_length → DoS), fixed in 1.6.7. Good to land.

Tier 2: Alignment Discussion

Principle Conflicts

None identified. Rewards-in-environment, client-server separation, the Gymnasium API, and the dual-API boundary are all untouched — this is a lockfile-only change.

RFC Conflicts

None identified.

Consistency / provenance (discussion point)

ALIGNMENT FLAG: Out-of-scope package-index migration rides along with the security bump

• Principle/RFC at stake: the reproducibility value in PRINCIPLES.md ("Container isolation for reproducibility", "Docker overhead is acceptable for reproducibility") and supply-chain/provenance consistency across envs.
• The concern: a narrow security bump silently switches the resolver index for these two envs from the HF internal mirror to public PyPI, plus a revision 2→3 schema bump. After this PR only 4 of 35 env lockfiles use pypi.org/simple (calendar_env, openapp_env, and now julia_env, jupyter_env); the other 31 use pypi.registries.huggingface.tech. There is no committed uv index config, so the index string just reflects wherever the re-lock ran. Functional risk is low: no lockfile pins artifacts to the HF host — every sdist/wheel URL already resolves to files.pythonhosted.org (the HF registry is a transparent mirror), so the pinned hashes are byte-identical either way. But the change (1) is out of scope for a joserfc bump, (2) increases repo drift, and (3) silently changes the declared supply-chain source for a whole env — a call worth making deliberately. calendar_env/openapp_env were flipped the same way in earlier roll-up PRs (#804/#770), so this is a recurring pattern worth standardizing: either configure the roll-up tooling with the HF index (and re-lock), or intentionally migrate all envs to public PyPI.
• Suggested reviewer: @burtenshaw (author of the aggregated dependabot roll-ups / repo dependency tooling) and @Darktex (author of the reproducibility lines in PRINCIPLES.md)

Summary

• 0 mechanical (Tier 1) issues — the joserfc security bump is clean and verified.
• 1 alignment point for human review — the unintended index + revision migration (repo consistency + declared provenance), low functional risk.
• 0 RFC conflicts.

  

_{Sent by Cursor Automation: Untitled}

[cursor]

This re-lock bumps the lockfile schema revision 2→3 and (in the ~128 entries below) rewrites every package's resolver index from pypi.registries.huggingface.tech to pypi.org/simple — unrelated to the joserfc 1.6.5→1.6.7 bump. Functional risk is low (all artifact URLs already resolve to files.pythonhosted.org, so hashes are unchanged), but it's a silent, out-of-scope provenance change: after this PR only 4/35 env locks use public PyPI. Consider re-locking with the HF index configured, or standardizing this across all envs. See the top-level review for detail.

[cursor]

Same pattern as julia_env: alongside the intended joserfc 1.6.4→1.6.7 bump, this re-lock bumps revision 2→3 and switches every package's index from pypi.registries.huggingface.tech to pypi.org/simple (~132 entries). Hashes are unchanged (artifacts still resolve to files.pythonhosted.org), so low functional risk, but it's an out-of-scope index migration that should be a deliberate, repo-wide decision rather than a side-effect of a dependabot bump.