perf(context,memory): binary search truncation and batch fidelity tag updates

[bug-ops]

Summary

• Replace sequential halving in truncate_to_tokens with binary search — preserves up to 2× more content per Compressed message at the same token budget
• Replace N sequential UPDATE messages SET fidelity_tag calls with a single batched CASE WHEN expression — reduces SQLite round-trips from N to ⌈N/333⌉ per scoring pass
• Add empty-slice early return to skip transaction entirely when no updates needed

Performance

Binary search (fidelity.rs):

• Before: O(log² N) — each halving halves the string, takes O(log N) iterations, each on a shorter prefix. At 90% truncation point, result was ~50% of content.
• After: O(N) total byte reads across O(log N) iterations converging on the exact maximum valid prefix. At 90% truncation point, result is ~90% of content.

Batch SQL (messages/mod.rs):

• Before: N sequential execute calls inside a transaction (N=200 → 200 awaits)
• After: ⌈N/333⌉ execute calls (N=200 → 1 await; N=500 → 2 awaits)
• MAX_FIDELITY_BATCH=333 keeps bind variable count within SQLITE_MAX_VARIABLE_NUMBER=999 (3 vars/row: 2 for CASE arm + 1 for IN list)

Test plan

• 7 new unit tests for truncate_to_tokens: no-op, exact limit, minimal truncation, 90%-preservation, empty string, max_tokens=0, multibyte UTF-8 boundary
• 2 new unit tests for update_fidelity_tags: single-item and multi-item batch
• 1 chunk-boundary regression test: N=334 (333+1 split) validates MAX_FIDELITY_BATCH constant
• 1640 tests pass, 8 skipped

Closes #4618
Closes #4619