Refactor Memrok around explicit local vs global representations

[MichaelSchmidle]

Ripe architectural follow-up from the v0.6.0 quality-loop work and the recent Honcho/Hermes comparison.

Goal

Introduce perspective-aware local vs global representations in Memrok as a first-class architectural concept.

Why

We keep encountering the same structural problem:

• broad/global memory is often useful in some contexts
• but it bleeds into topic-local contexts where it becomes noise

Right now this often looks like a retrieval bug. It may actually be a representation problem.

Instead of treating Memrok as one flat memory field with better or worse ranking, we should explore a model with at least:

• durable global representation
• local/topic/session representation
• clear rules for how local and global memory influence retrieval and injection

Motivation

This turns a recurring bug shape into an architectural move:

• global memory is not wrong
• local memory is not always sufficient
• the missing piece may be an explicit distinction between the two

Desired outcomes

• better topic-local precision without throwing away durable global context
• clearer reasoning about why a memory belongs in a given prompt
• stronger foundation for provenance, supersession, and future retrieval-mode control

Questions to answer

• what counts as global vs local in Memrok?
• how are local views created, updated, and expired?
• when should local memory override global memory?
• how should critic/eval tooling inspect failures across these layers?
• how does this relate to imported/bootstrap memory provenance?

Non-goal

• not a full policy-update loop
• not a service/platform sprawl move
• not a UI feature first

Likely impact

This may require revisiting the framing of provenance/import work (#10) and structural retrieval work (#12), because both could become cleaner when local/global representation is explicit rather than implicit.