fix(memory): stop extract_facts panicking on non-ASCII input

[harrythomasben]

Summary

Fixes #634. memory::extract::extract_facts panics on non-ASCII input: the explicit-"remember" fast-path guards a byte-index slice with only a byte-length check, so any utterance whose 8th byte falls inside a multi-byte UTF-8 char slices on a non-char-boundary and crashes. extract_facts runs on raw chat, voice-transcript, and profile-document text, so the input is user-controlled — this takes down fact extraction for any non-Latin-script household.

Changes

• Add a UTF-8-safe starts_with_ascii_ci(text, prefix) helper that uses str::get(..prefix.len()) (returns None on a non-char-boundary or too-short input) instead of a byte-length guard plus text[..n] slice.
• Use it at the "remember" call-site guard in extract_facts (was trimmed.len() >= 8 && trimmed[..8].eq_ignore_ascii_case("remember")).
• Use it for the twin byte slice in extract_remember (text[..PREFIX.len()]), which had the same unsound pattern.
• Add tests/extract_facts_utf8_test.rs: regression tests for CJK / accented / emoji input (no panic), short input, and the unchanged ASCII "remember" path.

Behavior is unchanged for ASCII input; the only difference is that non-ASCII utterances no longer panic (they correctly fall through the "remember" fast-path).

Real Behavior Proof

• I have built and run the affected code locally (or noted why I could not).
• I have verified the change end-to-end on Jetson hardware.
• I have NOT verified on Jetson hardware, and I explain the equivalent verification path or validation gap below.

Tested profile / hardware (check all that apply):

• jetson
• raspberry_pi
• portable_sbc
• laptop
• mac
• CI-only / docs-only
• Not run locally

What I ran

On an x86_64 Linux laptop (Rust 1.96):

• Reproduced the panic against the pre-fix logic with input "日本語hello":
  byte index 8 is not a char boundary; it is inside '語' (bytes 6..9 of string) (process aborted, exit 101).
• cargo test -p genie-core --test extract_facts_utf8_test → 4 passed.
• cargo test -p genie-core extract → 11 passed (existing extraction tests, no regression).
• cargo clippy -p genie-core --tests → clean; cargo fmt applied.

This is a pure input-parsing panic with no hardware, voice, audio, or Home Assistant dependency — the deterministic cargo test repro exercises the full fix path, so Jetson verification is not applicable.

What I observed

After the fix, extract_facts("日本語hello") and the other non-ASCII inputs return normally (no "remember" fact, no panic), while extract_facts("remember to call mom") and "Remember that ..." still extract the fact unchanged.

Test plan

1. cargo test -p genie-core --test extract_facts_utf8_test
2. cargo test -p genie-core extract to confirm existing extraction behavior is unchanged.

[matedev01]

LGTM — fixes non-ASCII panic in extract_facts. Needs rebase to resolve merge conflict (unrelated CHANGELOG clash). 826 lib, BFCL 96% after rebase.