[Feature]: Support async memory flush and configurable model for MemoryConsolidator/MemoryFlushManager

MemoryFlushManager.flushMemories() and MemoryConsolidator.consolidate() run synchronously after POST_CALL, blocking the response until all LLM-based memory operations complete. Both classes use the same model as the agent (passed via
constructor).

In production with remote filesystem (sandbox) + remote memory service, this adds 2-3 minutes to every response — 46% of total RT.

Timeline observed:
13:40:04 POST_CALL (agent response ready)
13:40:05 memory_search
13:41:15 flushMemories LLM call (70s gap)
13:43:32 consolidate LLM call (130s gap)
13:43:35 Response delivered to user (210s blocked)

Feature Request (two orthogonal improvements):

1. Configurable model for memory operations — Allow specifying a separate (faster/cheaper) model for MemoryFlushManager and MemoryConsolidator:
builder.memoryModel(fastModel) // e.g., qwen-turbo for memory, qwen-plus for reasoning
1. This alone could reduce 200s → 30-50s by using a faster model.
2. Async memory flush — Return the response to the caller immediately after POST_CALL, then run memory flush/consolidation in background:
builder.asyncMemoryFlush(true)
2. This would make user-perceived RT independent of memory operations.

Current workaround: Calling disableMemoryHooks() to skip framework memory entirely, then implementing custom async flush — but this loses the built-in consolidation logic.

Environment: HarnessAgent v1.1.0-RC2, remote sandbox filesystem, KBase memory service.