chore(deps): update rust crates

[xtqqczze]

No description provided.

[github-actions]

GNU testsuite comparison:

Note: The gnu test tests/dd/no-allocate is now being skipped but was previously passing.
Note: The gnu test tests/rm/many-dir-entries-vs-OOM is now being skipped but was previously passing.

[codspeed-hq]

Merging this PR will improve performance by 17.13%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
✅ 308 untouched benchmarks
⏩ 46 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	Simulation	true_consecutive_calls	199.4 ns	170.3 ns	+17.13%

---

_{Comparing xtqqczze:deps/lockfiles (32f8df0) with main (33745a0)}

Footnotes

1. 46 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/cut/bounded-memory (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/tty/tty-eof (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/date/date-locale-hour (passes in this run but fails in the 'main' branch)
Note: The gnu test tests/tail/tail-n0f is now being skipped but was previously passing.

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/pr/bounded-memory (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/tty/tty-eof (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/date/date-locale-hour (passes in this run but fails in the 'main' branch)
Note: The gnu test tests/basenc/bounded-memory is now being skipped but was previously passing.

[cakebaker]

Thanks!

[xtqqczze]

@cakebaker I think we should perform a lockfile update at least once every release cycle, probably just after a release?

[cakebaker]

@xtqqczze hm, I'm not sure. What would be the benefit?

[xtqqczze]

Running cargo update regularly ensures dependencies don’t become stale for long periods and can provide early detection of breakage from semver violations or newly introduced bugs.

In this instance, there was a performance benefit.

[cakebaker]

That makes sense. The "difficulty" I see is remembering to perform this task.

[xtqqczze]

I've just subscribed to release events for the repo, to remind me to do this from time to time. Longer-term it would probably be beneficial to include updating the dependencies post-release on some kind of checklist.