fix(commands): add sliding-window rate limiting to system-modifying commands

[anshul23102]

Description

kill_process, apply_optimization, rollback_optimization, and apply_boot_optimization could be called as fast as a caller could issue them. A scripted flood could kill processes in a tight loop or repeatedly trigger optimizations, driving the system into an unstable state.

Related Issue

Closes #48

Root Cause

No throttling mechanism existed for any Tauri command. Every request was processed immediately.

Changes Made

File	Change
src-tauri/src/system/rate_limiter.rs	New RateLimiter type. Tracks call timestamps per command in a trailing window using Instant (monotonic, so unaffected by clock changes). Rejected calls do not record a timestamp.
src-tauri/src/system/mod.rs	Registered and re-exported the new module
src-tauri/src/lib.rs	Added rate_limiter to AppState and an enforce_rate_limit helper. kill_process is capped at one call per second; the optimization commands at five per minute. Each command checks the limiter before acquiring any other lock.

Testing Done

cargo test --lib rate_limiter::
running 5 tests
test ...::allows_calls_up_to_the_limit ... ok
test ...::rejects_calls_beyond_the_limit ... ok
test ...::tracks_each_command_independently ... ok
test ...::window_expiry_allows_new_calls ... ok
test ...::rejected_call_does_not_consume_a_slot ... ok
test result: ok. 5 passed

Checklist

• Builds cleanly with cargo build
• All new unit tests pass
• No merge conflicts with the base branch
• Changes are focused on the reported surface

[Kanwaljeet1]

Hi @anshul23102 , please resolve the conflicts.

[anshul23102]

Conflicts resolved. The rate limiting checks are now properly sequenced after validation (fail fast on invalid ID, then check rate limits). Both PR #50 and this PR complement each other: #50 validates the optimization_id, and this PR adds rate limiting. Force-pushed the rebased solution.