fix(deps): pin find-msvc-tools 0.1.12 for Windows release builds

[ScriptedAlchemy]

Summary

• Pin find-msvc-tools to 0.1.12 in Cargo.lock so --locked Windows release builds can compile cc 1.2.67.
• Leave cc at 1.2.67. cc 1.4.7 is the crates.io release that accepts the new i32 constant, but this graph cannot select it.

Motivation

Release (Beta) run 35680014686 failed in Build x86_64-windows at "Build release binary for packaging" (rustc 1.97.1). Linux and macOS builds succeeded. The compiler error is in cc 1.2.67:

error[E0308]: mismatched types
  --> cc-1.2.67/src/tempfile.rs:33:9
   |
   | expected `u32`, found `i32`
   | ::find_msvc_tools::windows_sys::FILE_ATTRIBUTE_TEMPORARY

find-msvc-tools 0.1.13 (regenerated windows bindings, cc-rs #1919 / #1926) defines FILE_ATTRIBUTE_TEMPORARY as i32. cc 1.2.67 passes that constant straight into OpenOptionsExt::custom_flags, which takes u32. 0.1.12 still defines it as FILE_FLAGS_AND_ATTRIBUTES (u32).

cargo update -p cc --precise 1.4.7 does not resolve. tree-sitter-sequel 0.3.11 (latest on crates.io; pulled in by tokensave-large-treesitters) build-depends on cc = "~1.2.1". That range and the direct cc = "1" build-dependency unify on cc 1.2.67, whose find-msvc-tools requirement is ^0.1.9. Forcing a second cc 1.4.7 would still unify find-msvc-tools on 0.1.13, because 0.1.13 satisfies both ^0.1.9 and ^0.1.13, and the cc 1.2.67 copy would keep failing.

0.1.12 is the newest find-msvc-tools that still typechecks with that cc. 0.1.10–0.1.12 only bump MSRV/edition and tidy conditionals. The i32 change is exclusively 0.1.13.

Changes

• Cargo.lock: find-msvc-tools 0.1.13 → 0.1.12 (checksum = 3e0f1c7c3a72c66fd80abe965175f7523475c0489a87d3ff9d6e8c87d87a9d2d, matches crates.io). No other package versions move. cc stays 1.2.67.

A later cargo update that floats compatible crates will select find-msvc-tools 0.1.13 again until tree-sitter-sequel allows cc 1.4.7. Keep this pin until then.

Re-run Release (Beta) after merge

Do not re-dispatch v0.1.0-beta.48. Release (Beta) checks out the tag, and that tag still has find-msvc-tools 0.1.13.

After this lands on master, the next push runs Release Please, which opens the next beta release PR. Merging that PR tags the next prerelease (the current manifest is 0.1.0-beta.48) and release-please.yml dispatches Release (Beta) on master for the new tag. That dispatch is the Windows rebuild that contains this pin.

To recover that new tag by hand:

gh workflow run release-beta.yml --ref master -f release_tag=v0.1.0-beta.N

Test plan

• cc 1.2.67 + find-msvc-tools 0.1.13 fails cargo check --target x86_64-pc-windows-msvc on rustc 1.97.1 with E0308 (expected u32, found i32 at cc-1.2.67/src/tempfile.rs:33)
• cc 1.2.67 + find-msvc-tools 0.1.12 passes that same check (Finished dev profile)
• cargo tree -p tracedecay-cli -i find-msvc-tools --locked resolves only find-msvc-tools v0.1.12
• Full Windows cargo build --release --locked of tracedecay-cli (needs the Windows runner; this host typechecked the failing cc crate for x86_64-pc-windows-msvc only)

  

[changeset-bot]

⚠️ No Changeset found

Latest commit: 680599e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-22T06:07:34.951802Z	09fdd74	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.