feat(memory): add a minimum-age grace period before auto-prune

[tars23364-bit]

What

Adds MNEMON_PRUNE_MIN_AGE, a grace period below which AutoPrune will not take an
insight. An insight younger than the configured duration is spared regardless of
importance, access count, or effective_importance.

Unset (the default) is an exact no-op: auto-prune behaves as it does today.

Why

AutoPrune's capacity check runs on every remember and every import. In a store
that sits over capacity, that means a prune pass fires on every single write — so a
newly created insight can be soft-deleted in the same second it was created, before
anything has read it once.

That is the hole this closes. A low-importance insight has exactly two protections:
importance >= 4 and access_count >= 3. Neither can help a fresh write. Importance
is fixed at write time, and access_count cannot rise until something reads the
insight — which is precisely what has not had the chance to happen yet. Age is the only
signal that distinguishes "this was judged and found weak" from "nothing has looked at
it yet."

On my own store this is not hypothetical: it runs permanently over the 1000 cap, so
every write triggers a prune pass, and I have measured writes reaped under a second
after insert. v0.2.1's per-prune oplog row (#96) made that visible; this makes it
avoidable.

This is request 2 of #83.

How

One extra predicate on the candidate query in autoPrune:

AND created_at <= ?

with the cutoff formatted the same way GetRecentInsightsInWindow already formats its
window bound. Resolution happens at call time (store.PruneMinAge()), so callers and
tests that set the variable after start-up see the value they set. An unparseable or
negative value is reported on stderr and ignored rather than applied, so a typo cannot
silently widen what auto-prune is allowed to take.

Scoped deliberately to AutoPrune. mnemon gc's suggest mode still lists young
insights as retention candidates — that path is advisory and drives an explicit
operator forget, which should stay able to name anything. Happy to extend it there
too if you would rather the two agreed.

One interaction worth naming: in a store already over capacity, a grace window
longer than the age of every prunable insight starves the candidate set — auto-prune
finds nothing on any pass and the store grows past the cap until the oldest
candidates age out of the window. That is the intended reading of an opt-in grace
period (the operator has said "never take anything this young"), not a bug, but it
means a large value trades the cap's firmness for the grace guarantee. The sibling
PR #109 making the insight ceiling configurable (#83 request 3) is the right lever for
anyone who finds themselves there deliberately.

Checklist

• Deterministic tests pass (make test)
• Relevant E2E/process/Docker boundaries pass (make test-integration) — not
  affected; no CLI surface, Agency, process, or Docker boundary changes
• New/changed behavior is covered by tests — a spared young insight, the
  unset-default path, and env resolution including the typo and negative cases
• Documentation updated — MNEMON_PRUNE_MIN_AGE added to the Configuration
  tables in docs/USAGE.md and docs/zh/USAGE.md
• Release-note impact: new optional environment variable; no default behavior
  change

Notes

The default is off rather than some sensible non-zero value, to keep this a pure
opt-in with no behavior change for existing stores. If you would rather ship a default
grace period (24h would cover the same-second reaping case), say so and I will change
the constant.

Sibling PR: #109 (#83 request 3). Semantically independent; both touch the same Configuration table rows and lifecycle const block, so whichever merges second carries a trivial keep-both rebase — the conflicts are expected.