feat(retrieval): add fresh memory boost for recently stored memories

[raw34]

Memories stored within 30 minutes (configurable) get an additional score boost (+0.15), with an extra +0.05 for reflection/preference categories. This ensures corrections from ongoing conversations outrank stale high-access memories in auto-recall ranking.

Configurable via retrieval.freshMemoryBoostMinutes (default: 30,
set 0 to disable) and retrieval.freshMemoryBoostWeight (default: 0.15).

[raw34]

CI failures are pre-existing on master — not introduced by this PR. See #657 for the fix. Once that's merged, this PR will pass CI after a rebase.

[app3apps]

Thanks for the work on this. I didn’t find a clear blocker in this pass, but I’m stopping at a comment-only review rather than an approve.

The main reason is confidence, not direction:

• The targeted tests pass, but the new test coverage does not exercise the production MemoryRetriever path directly.
• The full suite is still red.
• The branch is stale, so I’d rather not overstate confidence from a partial pass.

My current read is: the idea looks reasonable and may be fine to merge after a maintainer sanity-check, but I don’t think this review pass is strong enough to treat it as a clean approve.

[app3apps]

Thanks for the patch. I like the intent here, but I don’t think the feature is actually wired through in the default runtime yet, so I’m stopping at request changes.

1. fresh memory boost is bypassed in the normal plugin path
   In the main app wiring we always construct the retriever with a decayEngine (index.ts:1756-1768). But all three retrieval paths skip applyRecencyBoost(...) when decayEngine is present (src/retriever.ts:767-771, 852-860, 1004-1012).
   The new bonus logic only exists inside applyRecencyBoost(...) (src/retriever.ts:1374-1387), so in the default runtime these new knobs appear to be a no-op.

2. The new test does not protect the production behavior
   test/fresh-memory-boost.test.mjs manually recomputes scores instead of exercising MemoryRetriever / createRetriever, so it would still pass even if the runtime behavior above never changes.
   Also, this repo’s CI is manifest-driven: workflows only run the groups from .github/workflows/ci.yml:24-112, and the new test file is not present in scripts/ci-test-manifest.mjs:9-57, so CI never runs it.

3. The new knobs are not independent from the existing recency boost
   applyRecencyBoost(...) returns early when recencyWeight is falsy or recencyHalfLifeDays <= 0 (src/retriever.ts:1355-1358). That means a config like freshMemoryBoostMinutes > 0 with recencyWeight: 0 silently disables the fresh-memory bonus too, which doesn’t match the PR description of these as separate controls.

If the goal is for this to affect real retrieval behavior, I think the fix is to move the fresh-memory bonus into the decay/lifecycle path as well, then add a production-path test that instantiates the retriever the same way the plugin does and wire that test into the CI manifest.