fix: replace mutex unwrap with proper error handling (#333)

[Wirasm]

Summary

get_process_metrics() at crates/kild-core/src/process/operations.rs:136 used .unwrap() on SYSTEM.lock(), which is the only production .unwrap() on a fallible mutex operation in the codebase. If the mutex is poisoned (another thread panicked while holding the lock), this panics instead of returning an error.

Root Cause

Missing .map_err() conversion from PoisonError to ProcessError::SystemError. The SystemError variant already existed but wasn't used for this case.

Changes

File	Change
crates/kild-core/src/process/operations.rs	Replace .unwrap() with .map_err() converting to ProcessError::SystemError

The caller (health/handler.rs:82) already handles Result gracefully via Option, so the error is logged and health monitoring degrades gracefully.

Testing

• cargo fmt --check passes
• cargo clippy --all -- -D warnings passes
• cargo test --all passes
• cargo build --all passes

Validation

cargo fmt --check && cargo clippy --all -- -D warnings && cargo test --all

Issue

Fixes #333

[Wirasm]

Self-Review

Summary

Clean, minimal fix that eliminates the only production .unwrap() on a fallible mutex operation in the codebase.

Findings

Strengths

• Follows the established mutex error handling pattern from kild-ui/src/terminal/state.rs:332-335
• Reuses existing ProcessError::SystemError variant — no new types needed
• Event name core.process.metrics_lock_failed follows the documented {layer}.{domain}.{action}_{state} convention
• Caller in health/handler.rs:82 already handles Err gracefully, so degradation is seamless

Security

• No security concerns. Removes a panic vector.

Checklist

• Fix addresses root cause (.unwrap() → .map_err())
• Code follows codebase patterns
• No obvious bugs introduced
• All validation passes (fmt, clippy, test, build)