[Feature]: OpenViking-backed long-term memory backend

## Summary

I would like to discuss adding an optional OpenViking-backed long-term memory backend to QwenPaw using the existing 'BaseMemoryManager' / 'MemoryMiddleware' architecture.

Before preparing a full PR, I would like to confirm whether this direction fits QwenPaw's current long-term memory architecture and whether maintainers would be interested in accepting an 'OpenVikingMemoryManager(BaseMemoryManager)'.

## Component(s) Affected

- [x] Core / Backend (app, agents, config, providers, utils, local_models)
- [x] Console (frontend web UI)
- [ ] Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.)
- [ ] Skills
- [ ] CLI
- [x] Documentation (website)
- [x] Tests
- [ ] CI/CD
- [ ] Scripts / Deploy

## Problem / Motivation

QwenPaw now provides a backend-neutral long-term memory lifecycle through`BaseMemoryManager`and `MemoryMiddleware`.

The existing ADBPG backend demonstrates that a remote HTTP memory service can
participate in this lifecycle through automatic pre-model recall, asynchronous post-turn persistence, backend-specific configuration, and an explicit `memory_search` tool.

My interest in OpenViking is therefore not simply to add another remote memory service.

OpenViking's conversational memory lifecycle is organized around Sessions. A session stores conversation messages and, when committed, archives the committed session messages and asynchronously performs summary generation and long-term memory extraction.

Its memory extraction flow can generate candidate memories, compare them against existing memories, and make create / merge / delete decisions before persisting the result. Memory changes are also recorded for auditing.

For retrieval, OpenViking supports session-aware search. It also provides an optional server-side context-assembly mode that can return relevant context under a configurable token budget.

I previously implemented and validated an OpenViking integration against QwenPaw 1.0.1 and OpenViking 0.4.1. In a small exploratory test, I observed some cases where the OpenViking-backed integration retrieved useful prior context more reliably than my ReMeLight baseline. This was not a controlled benchmark, so I do not want to make a general performance claim from it. If this direction is of interest, I would like to repeat the comparison on the current QwenPaw architecture using the same model, workload, retrieval budget, and evaluation criteria.

Because that QwenPaw version did not expose the current memory lifecycle, the integration intercepted `AgentRunner.query_handler` to perform recall before a reply and asynchronous session persistence afterwards. The current `BaseMemoryManager` / `MemoryMiddleware` architecture should allow the same lifecycle to be implemented without runtime monkey patching.

## Proposed Solution

For an initial, intentionally limited implementation, I propose an OpenVikingMemoryManager(BaseMemoryManager).

1. Backend configuration

Use get_memory_config() to expose OpenViking-specific settings such as:

OpenViking server endpoint
authentication credentials
retrieval token budget
automatic retrieval settings
session commit / auto-commit behavior

2. Automatic memory recall

Implement auto_memory_search() using OpenViking's session-aware retrieval before the model call.

One option for `auto_memory_search()` is to use OpenViking's `search(mode="context")` with retrieval restricted to Memory.

This could let OpenViking handle token budgeting, tier fallback, and optional cross-turn deduplication server-side, instead of implementing those context assembly steps in the QwenPaw adapter.

3. Automatic persistence

Implement auto_memory() to append sanitized completed conversation turns to the corresponding OpenViking session asynchronously.

The integration should not hard-code a `commit()` after every QwenPaw turn. Explicit commit or OpenViking's configurable auto-commit policy can determine when memory extraction is triggered.

When a commit occurs, OpenViking can archive session messages and perform long-term memory extraction asynchronously, including deduplication and create/merge/delete decisions against existing memories.

4. Explicit memory search

Expose `memory_search` through `list_memory_tools()` so the agent can perform additional memory retrieval when needed during a task, in addition to the automatic recall performed by `MemoryMiddleware` before model execution.

5. Lifecycle and failure handling

The integration should use asynchronous HTTP access and fail open when the OpenViking service is temporarily unavailable, so normal QwenPaw conversations can continue.

## Alternatives Considered

''Expose OpenViking only through tools / MCP'' can expose explicit OpenViking operations to the agent, but it does not by
itself make OpenViking participate in QwenPaw's native automatic pre-model recall and post-turn memory lifecycle.

ADBPG is already implemented through the same `BaseMemoryManager` abstraction, and #7080 is exploring another memory backend. I would like to align the implementation with QwenPaw's current memory architecture before starting a larger PR.

## Additional Context

Relevant QwenPaw history:

#2308 — initial ADBPG memory backend
#5296 — REST-only ADBPG and backend-neutral MemoryMiddleware integration
#7080 — PowerContext memory backend proposal

If maintainers are interested in this direction, I can first provide a small implementation against the current QwenPaw main branch and current OpenViking release, followed by end-to-end validation of:

QwenPaw → OpenViking session mapping
session message persistence
explicit commit / auto-commit behavior
automatic recall
explicit memory search
context token budgeting
failure handling

I am also interested in an apples-to-apples evaluation against existing QwenPaw memory backends.

The OpenViking behaviors referenced in this proposal were checked against OpenViking v0.4.15.

## Willing to Contribute

- [x] I am willing to open a PR for this feature (after discussion).