fix(harness): 将记忆刷写与压缩流程切到阻塞线程池

[guslegend0510]

描述

背景

PR #1480 的核心目标是避免在 Reactor 非阻塞线程上执行记忆刷写、压缩和卸载这类阻塞操作。由于旧的 autocontext 模块已经不在主线上，这次把修复迁移到了当前 agentscope-harness 的 memory pipeline。

主要改动

MemoryFlushManager.flushMemories() 拆分了输入构造、模型流式处理和文件写入步骤。
将涉及文件 IO / 模型流处理的逻辑切到 Schedulers.boundedElastic()，避免阻塞调用占用非阻塞线程。
ConversationCompactor.compactIfNeeded() 改为延迟执行，并切到 boundedElastic。
offload 路径解析等阻塞步骤也显式切换到 boundedElastic。
新增回归测试，覆盖 non-blocking scheduler 场景下的线程切换行为。

验证

mvn -pl agentscope-harness "-Dtest=ConversationCompactorTest,MemoryFlushManagerTest" test

[codecov]

Codecov Report

❌ Patch coverage is 73.07692% with 7 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...scope/harness/agent/memory/MemoryFlushManager.java	68.18%	3 Missing and 4 partials ⚠️

📢 Thoughts on this report? Let us know!

[AgentScopeJavaBot]

🤖 AI Review

This PR addresses a reactive anti-pattern where blocking filesystem I/O (workspace file reads/writes in MemoryFlushManager and ConversationCompactor) was executing on Reactor's non-blocking scheduler threads. The fix correctly offloads these blocking operations to Schedulers.boundedElastic() using the standard Reactor patterns. Additionally, a bug in ToolCallParam.Builder's copy constructor is fixed. Both new test classes directly assert that blocking I/O does not run on non-blocking threads via Schedulers.isInNonBlockingThread().

[LearningGp]

[guslegend0510]

@LearningGp ，

已解决，麻烦重新审核一下，谢谢