fix(tui): stop long-lived timer thread accumulation

[cbusillo]

Summary

• stop leaked composer animation threads when the composer is dropped
• replace rate-limit reset sleeper threads with a tracked cancellable Tokio task
• add regression coverage for both thread accumulation paths

Why

Recent Every Code crash logs showed the TUI exhausting the 32-thread lightweight background pool over long-lived sessions. The original composer cleanup fixed one real leak, but fresh logs still showed saturation with rate-reset-refresh participating as a second long-lived sleeper path. This PR fixes both accumulation sites together.

Validation

• cargo test -p code-tui drop_stops_running_animation_thread -- --nocapture
• cargo test -p code-tui repeated_rate_limit_reschedules_do_not_consume_lightweight_threads -- --nocapture
• PROFILE=release-prod ./build-fast.sh

Runtime check

• ran the patched release-prod binary locally
• observed a live t3code session on the new build run for about 3 hours with no new background thread spawn rejected entries after session start in ~/.code/debug_logs/critical.log.2026-03-10
• note: the older vulnerable build could still survive for hours depending on workload, so this soak is supporting evidence rather than a proof by itself