chore(deps): bump uuid from 1.25.0 to 1.26.0

[dependabot]

Bumps uuid from 1.25.0 to 1.26.0.

Release notes

Sourced from uuid's releases.

v1.26.0

What's Changed

• Add ContextV7::with_additional_precision_bits by @​ChrisJr404 in uuid-rs/uuid#904
• Prepare for 1.26.0 release by @​KodrAus in uuid-rs/uuid#905

Full Changelog: uuid-rs/uuid@1.25.0...v1.26.0

Commits

• cdc96a8 Merge pull request #905 from uuid-rs/cargo/v1.26.0
• 34e4f49 don't test macros under miri
• d9e7242 update nightly used for miri
• ec16819 prepare for 1.26.0 release
• 162cd20 Merge pull request #904 from ChrisJr404/v7-additional-precision-bits
• 97eceff Add ContextV7::with_additional_precision_bits for microsecond clocks
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[seonghobae]

Exact-head dependency-reproducibility finding on 3af905e724eaaa99fb9edc65b556ef407c5ae685.

This PR updates only the workspace-root Cargo.lock from uuid 1.25.0 to 1.26.0 (b5772d71...), while the independently shipped/executed PyO3 binding lock crates/fast-mlsirm-py/Cargo.lock still resolves the same mlsirm-core direct dependency to uuid 1.25.0 (f0535769...). CLAUDE.md explicitly records that the binding crate is workspace-excluded and is tested through its own manifest, so the second lock root is not inert metadata.

I moved this PR to Draft and added RED 426862eefae51831e011e7c0b59f19ac1b5fceae: tests/test_rust_shipping_lock_parity.py parses both shipping lock roots with tomllib and requires the registry version+checksum identity for uuid to match. On the current tree it deterministically fails as intended: root = 1.26.0, binding = 1.25.0.

Minimal causal repair is to regenerate/update crates/fast-mlsirm-py/Cargo.lock under the reviewed Rust toolchain so uuid is exactly 1.26.0 with checksum b5772d71c9be8a8a6ac2117d949c5b224c1b72241bb611d9a3012edcf8af7812, then run both cargo test --workspace --locked and cargo test --locked --manifest-path crates/fast-mlsirm-py/Cargo.toml plus the new Python contract. Do not delete the nested lock, broaden the dependency constraint merely to make resolution move at runtime, or treat a root-only Cargo GREEN as package reproducibility evidence.

[seonghobae]

Fresh review confirms this Draft is a real dependency-provenance RED, not a clean root-lock bump. Exact head 426862eefae51831e011e7c0b59f19ac1b5fceae moves root Cargo.lock UUID 1.25.0 -> 1.26.0, but the shipping workspace-excluded crates/fast-mlsirm-py/Cargo.lock still resolves UUID 1.25.0 with the predecessor checksum. The added test_uuid_identity_matches_all_shipping_lock_roots therefore intentionally fails on this head.

The causal prevention layer is #1697, which has now been non-force restacked onto protected main@493326f2de49ea1704da0ded19868ed05d2fe00f at exact head 056dda786b4dc623d4b2d71da59ee7bae5d930c8. It groups the independently locked Cargo roots under one dependency-name update lane rather than letting Dependabot produce a root-only shipping update. Keep #1776 Draft and preserve its valid UUID 1.26.0 delta/test; do not close it, weaken parity, or hand-edit away the evidence. After the foundation lands, this child should be refreshed/recreated through the grouped owner path so all applicable shipping locks move together.

Current #1776 repository CodeQL is success; CI is skipped because the PR is Draft, while CodeQL PR/Security/Semgrep remain non-terminal. None of that converts the current split-lock RED into GREEN.

[seonghobae]

Draft RED remains valid on exact head 426862eefae51831e011e7c0b59f19ac1b5fceae against main@493326f2de49ea1704da0ded19868ed05d2fe00f.

The PR updates only root Cargo.lock from uuid 1.25.0 to 1.26.0, while crates/fast-mlsirm-py/Cargo.lock still resolves uuid 1.25.0; the added shipping-lock parity contract therefore fails for a real reproducibility divergence rather than a flaky or over-broad test. Do not delete/weaken that contract and do not hand-edit the Dependabot branch as a one-off substitute for the owner fix.

Prerequisite #1697 is now Ready at exact 056dda786b4dc623d4b2d71da59ee7bae5d930c8, merge-base current protected main, with effective delta limited to the grouped Cargo Dependabot config and its contracts. GitHub's current Dependabot docs confirm cross-directory group-by: dependency-name for version updates and applies-to: security-updates grouping for security updates. #1697 exact-head CI and repository CodeQL are GREEN; remaining hosted gates/review are not yet terminal.

Acceptance for this lane after #1697 lands: preserve the UUID 1.26.0 update, let the grouped Cargo owner path regenerate/update all affected shipping lock roots in one PR, require root/PyO3 UUID (version, checksum) identity GREEN, then run the normal exact-head package/Rust/Python/security gates. Until then, keep #1776 Draft and do not claim release readiness.