[Feature]: Add recall-aware signals to dream memory consolidation

## Summary

Add an optional recall-aware consolidation mechanism that uses repeated, meaningful recalls of daily memories as an additional signal when deciding what should be distilled into `MEMORY.md`.

The goal is not to promote a memory simply because it was retrieved several times. Recall frequency, query diversity, relevance, recency, and source provenance should help identify candidates, while the existing dream process remains responsible for distillation, deduplication, and long-term memory updates.

## Component(s) Affected

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

## Problem / Motivation

QwenPaw already writes daily memory files and periodically consolidates them through dream optimization. However, consolidation is mostly based on the content available during that dream pass.

A useful item may remain only in an older daily file if it was not selected at that time, even when it later proves valuable across several conversations. Repeated recall from distinct user queries can provide evidence that the item has durable value.

For example, a note such as:

```text
Run a migration dry-run before every production deployment.
```

may later be recalled for deployment preparation, migration procedure, and production checklist questions. That repeated use is a useful signal for future consolidation, but it is not currently available to the dream process.

## Proposed Solution

Introduce an optional recall-aware candidate flow:

1. Track only final `memory_search` results surfaced to the agent from dated daily files matching `memory/YYYY-MM-DD.md`.
2. Store lightweight signals such as recall count, distinct query count, average relevance, first/last recall time, content hash, and source location.
3. Rank recent candidates using multiple signals, including frequency, query diversity, relevance, and recency.
4. Before consolidation, re-read the live source and discard candidates whose content was edited or deleted.
5. Supply qualified candidates to the existing dream process as additional evidence.
6. Let dream distill, deduplicate, resolve conflicts, and merge durable information into `MEMORY.md`.
7. Keep the feature disabled by default while its thresholds and behavior are evaluated.

Recall scores should influence candidate selection, but should not directly append raw snippets to `MEMORY.md`.

## Safety and Quality Requirements

- Exclude cron deliveries, runtime-only events, system announcements, and other one-way generated reports.
- Exclude content generated by dream or other memory-maintenance jobs to prevent feedback loops.
- Do not treat repeated identical queries as independent query-diversity evidence.
- Do not track recalls of `MEMORY.md`; this proposal is specifically about promotion from daily memory.
- Never write raw candidate metadata or internal pipeline artifacts into `MEMORY.md`.
- Preserve source provenance so consolidation decisions remain reviewable.
- Make repeated dream runs idempotent and avoid duplicate long-term entries.
- Fail safely: recall tracking should never block or break `memory_search`.

## Alternatives Considered

### Rely only on the existing dream prompt

This keeps the system simple, but the dream process has no evidence that an older daily note became repeatedly useful after its original consolidation window.

### Promote after a fixed number of recalls

Recall count alone is vulnerable to ranking feedback loops, repeated automated queries, and noisy system-generated content. It should be combined with query diversity, relevance, recency, and provenance filtering.

### Append qualified snippets directly to `MEMORY.md`

This would create a second long-term memory writer and could conflict with dream consolidation. It could also preserve raw or outdated wording instead of producing a concise, conflict-aware long-term memory.

## Additional Context

QwenPaw is currently migrating its memory runtime to ReMe4 in #5349. I would be happy to work on a PR if this direction makes sense, but I would first like to confirm the preferred contribution path: should new memory algorithms like this generally be implemented in ReMe4 and then integrated into QwenPaw, or should this behavior live in QwenPaw's memory integration layer?

A possible test matrix includes:

- distinct user-originated recalls produce a consolidation candidate
- repeated identical queries do not satisfy the diversity gate
- cron, system, and dream-generated content remains ineligible
- edited or deleted source snippets are rejected before consolidation
- an equivalent existing long-term memory is merged rather than duplicated
- disabling the feature preserves current behavior

This idea is related to recall-aware short-term promotion systems, but is intentionally framed around QwenPaw's existing dream consolidation flow rather than direct raw promotion.

## Willing to Contribute

- [x] I am willing to open a PR after maintainers confirm whether the implementation should target ReMe4 or QwenPaw.