fix(deps): bump mio to 1.2.3 to stop Windows daemon panic

[posthog]

Problem

• Windows users hit a daemon-killing panic: panic: CANCEL ERROR Os { code: 1168, ... "Element not found." } (Windows ERROR_NOT_FOUND).
• Root cause is mio 1.2.0, not our code. Its Windows AFD selector panics when an I/O cancel returns error 1168, which happens when the I/O request already finished.
• Impact: a panic aborts the daemon process. It is a timing race that any Windows user can trip.

Changes

• Bump mio 1.2.0 → 1.2.3 in Cargo.lock. Upstream replaced that panic with normal error propagation in 1.2.3, so the panicking branch no longer exists.
• Lockfile only — no source change. The dependency graph is unchanged, and tokio 1.52.3 requires mio ^1.2.0, which 1.2.3 satisfies.

 name = "mio"
-version = "1.2.0"
+version = "1.2.3"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "50b7e5b27aa02a74bac8c3f23f448f8d87ff11f92d3aac1a6ed369ee08cc56c1"
+checksum = "4b18443e9c262bfe8fa82f51666e2642c53393f7e5c27b3e1aeab922cff5b9d8"

Verification

• cargo check --locked passes (crate autter v1.7.5).

Risk

• Low. Patch-level bump within the same minor line; resolved dependencies are unchanged.

Agent context

• The inbox report named the autter-runtime repository, but that repo is the TypeScript telemetry SDK and has no Rust code. The panicking code (Cargo.lock, src/daemon/telemetry_worker.rs, src/observability/mod.rs) lives here in autter-cli, so the fix landed here.
• Optional follow-up noted in the report, not included to keep this change minimal: attach the panic location and a backtrace to the exception properties, so future panics arrive with a stack trace.

---

Created with PostHog Desktop from this inbox report.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}