feat: trace the Memory read path

[PsiACE]

Feature description

Add bounded tracing for Memory search, reranking, and context preparation.

Problem and proposed solution

search_memory and prepare_context currently expose only the outer application span. Add enough detail to show which read stage ran, how many candidates were handled, and where latency or failure occurred.

Possible trace structure:

powercontext search_memory
└── memory.search
    ├── embeddings <model>
    └── memory.rerank
        └── invoke_agent memory_rerank

powercontext prepare_context
├── memory.search
├── experience.search
└── context.prepare

Do not record queries, prompts, Memory content, or vectors.

The PR should include an exported span tree or dashboard screenshot.

Alternatives considered

Keep the existing application span only.

Additional context

Part of #1214. Tracing remains optional and must not change Runtime behavior.

[Kairo-J]

Hi @PsiACE , I’d like to work on this issue if it’s still available. I plan to add bounded spans for Memory search, reranking, Experience search, and context preparation, with tests and an exported span tree. I’ll ensure no queries, content, prompts, or vectors are recorded. Could you assign it to me?

[PsiACE]

Hi @Kairo-J , I've already assigned it to you, thanks

[Kairo-J]

@PsiACE ,I plan to keep OpenTelemetry owned by ServerTracing and inject a small internal, framework-neutral RuntimeTracing port into BuiltinRuntime. Runtime will not import OpenTelemetry. For stable traces, memory.search and experience.search will also be emitted when data or configuration is absent, using only booleans and counts; memory.rerank will wrap actual reranker calls only. Is this boundary and behavior acceptable?