chore: audit and eliminate panicking unwrap() in library code

[randomm]

What

Library code contains panicking unwrap() calls that violate our own AGENTS.md rule:
"no unwrap() in library code, only in tests."

Part of EPIC #88 (open-source readiness).

Locations

• src/pattern.rs — 10× unwrap() at lines 115, 117, 126, 131, 140, 142, 151, 156 (Regex::new on hardcoded patterns)
• src/session.rs — 2× unwrap() at lines 27, 43 (git URL/dir parsing)
• src/learn.rs — 1× unwrap() at line 90 (config parsing)
• src/init.rs — 6× expect() calls (panicking)

Note: classify.rs:46,49 and learn.rs:344,347 use unwrap_or() which is safe — not a violation.

Why

Panicking in library code is embarrassing for an open-source project, especially one that
claims proper error handling via thiserror. The Regex::new calls on hardcoded patterns are
technically safe (they will not fail at runtime), but should use expect("reason") or
compile-time validation to signal intent.

Acceptance Criteria

• Zero unwrap() calls in src/ outside of #[cfg(test)] blocks and main.rs
• Regex compilations use expect("valid regex: ...") or lazy_static/once_cell
• Session and learn parsing use proper Result propagation
• init.rs expect() calls have descriptive messages or use ?
• cargo clippy -- -D warnings passes
• All existing tests still pass