fix: replace bare unwrap() with expect() in production code

[ztsalexey]

Summary

• Replace all 31 bare .unwrap() calls in production code with .expect("reason") or idiomatic alternatives across 9 files
• After this change, zero .unwrap() calls remain in non-test code
• All replacements are in cases where the unwrap is logically safe but lacked documentation:
  • safety/leak_detector.rs: 16 hardcoded Regex::new() patterns — always valid at compile time
  • safety/sanitizer.rs: 4 hardcoded Regex::new() patterns — same
  • sandbox/proxy/http.rs: 3 Response::builder() chains — status/headers/body always valid
  • setup/wizard.rs: 2 state unwraps — guarded by control flow (set in prior steps)
  • workspace/chunker.rs: 2 chunks.pop() calls — both guarded by !chunks.is_empty() check
  • workspace/repository.rs: 1 embedding.unwrap() — guarded by embedding.is_some() check
  • settings.rs: 1 parts.last().unwrap() — guarded by parts.is_empty() early return
  • tools/builder/core.rs: 1 serde_json::to_string().unwrap() — simple struct serialization
  • cli/tool.rs: 1 check.unwrap() — replaced with map_or pattern (eliminates unwrap entirely)

Motivation

CLAUDE.md states: "Never use .unwrap() in production code (tests are fine)". A full audit found 31 bare .unwrap() calls in non-test code. While all are logically safe, replacing them with .expect() adds documentation for future readers and gives clear panic messages if assumptions are ever violated.

Test plan

• cargo test --lib — all 524 unit tests pass (no test changes in this PR)
• cargo check — compiles cleanly
• Verified zero .unwrap() in production code after this change
• Review each replacement to confirm the expect() reason is accurate

[ztsalexey]

nope