fix(benchmarks): UTF-8 encoding + ASCII print chrome on Windows for the 3 sibling runners

[jphein]

Summary

Follow-up to #1204 (LongMemEval Windows encoding) per @mschultheiss83's request. Applies the same narrow Windows correctness pattern to the three sibling benchmark runners that share the same shape:

• benchmarks/locomo_bench.py
• benchmarks/membench_bench.py
• benchmarks/convomem_bench.py

What changed (per file)

• All local open(path) / open(path, "w") calls now pass encoding="utf-8" (was inheriting the platform default — cp1252 on Windows, GBK on Chinese Windows). Mirrors benchmarks: harden longmemeval runner for Windows encoding #1204's pattern at longmemeval_bench.py:2917 / :2927 / :2957 / :2998 / :3031.
• Non-ASCII separator characters in print(...) chrome replaced with ASCII (─ → -, → → ->) so a default cp1252 console doesn't raise UnicodeEncodeError mid-run. Comments/docstrings (which never hit stdout) are untouched.
• urllib.request.urlopen(...) calls intentionally left alone — they don't open local files, and the original benchmarks: harden longmemeval runner for Windows encoding #1204 audit didn't flag them.

Total diff: +16 / -16 across 3 files. No behavior change beyond Windows correctness.

Audit provenance

The file selection isn't speculative — jphein already audited the codebase in #1204's review thread and flagged the exact open(...) lines in these three files. @mschultheiss83 asked for the follow-up at #1204 (comment). This PR is just the mechanical follow-through.

Out of scope

• The pre-existing C901 ruff finding on locomo_bench.py:621 (run_benchmark complexity 36) is from upstream develop (verified by stash + re-lint on stock branch); not from this PR.
• Non-encoding-related Windows fixes (path separators, line-ending handling) — those would be a different audit.

Test plan

• CI green on Linux / macOS / Windows
• Manual smoke (Linux): each of the three runners imports without error and the read/write paths exercised by --cache-dir arguments don't regress
• No new ruff lint errors introduced (verified locally — pre-existing C901 unchanged)

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR hardens the three benchmark runner scripts (locomo, membench, convomem) for native Windows execution by making local JSON file I/O explicitly UTF-8 and replacing non-ASCII console separators/arrows that can trigger UnicodeEncodeError on default cp1252 terminals.

Changes:

• Add encoding="utf-8" to local open(...) calls used for reading/writing JSON caches and results in the three runners.
• Replace non-ASCII console “chrome” characters (─, →) used in print(...) output with ASCII-safe equivalents (-, ->).

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
benchmarks/membench_bench.py	Explicit UTF-8 for JSON file read/write; ASCII-only separator output.
benchmarks/locomo_bench.py	Explicit UTF-8 for dataset/cache/results I/O; ASCII-only separator and progress output.
benchmarks/convomem_bench.py	Explicit UTF-8 for cache/result JSON I/O; ASCII-only separator output.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mschultheiss83]

@bensig @milla-jovovich please review...

[jphein]

Trivial Windows fix: adds explicit encoding="utf-8" to the local JSON I/O in the three benchmark runners and swaps the non-ASCII console chrome (─, →) for ASCII so default cp1252 terminals don't raise UnicodeEncodeError. +16/-16 across the three sibling runners, no behavior change off Windows. Thanks @mschultheiss83 for flagging interest above — should be a quick one to land. Merges clean on develop.