fix: extract content from function responses in session memory

[yashrajshuklaaa]

What

Extracts text content from FunctionResponse parts when building session content for memory summarization, instead of silently dropping them.

Why

extractSessionContent in kagent_service.go builds a text summary of a session's events for memory storage. Previously, when a part had no Text but did have a FunctionResponse (i.e. a tool call result), the content was skipped entirely via a // TODO: Extract content from function response if needed and a continue. This meant tool outputs were invisible to session
memory summarization, only user/agent text made it in, even though tool results are often the most useful context to remember (e.g. "what did the weather API return").

Change

• Marshal part.FunctionResponse.Response (a map[string]any) to JSON and include it in the extracted content, prefixed with
  [tool result from <function_name>]: so it's distinguishable from regular text in the summary.
• Falls back to skipping the part (same as before) if marshaling fails or produces an empty result, so this can't panic or inject garbage into the summary.

Testing

• Added newMockEventWithFunctionResponse test helper alongside the existing newMockEventWithFunctionCall.
• Added a new case to TestKagentMemoryServiceExtractSessionContent covering a function-response-only event and asserting its content is present in the output.
• Ran locally:
  • gofmt -l , clean
  • go vet ./adk/pkg/memory/... , clean
  • go test -race ./adk/pkg/memory/... , pass
  • golangci-lint run ./adk/pkg/memory/... , 0 issues

Scope

Small, self-contained change to a single function in one package. No new dependencies, no API/behavior changes outside of extractSessionContent.

[supreme-gg-gg]

Function responses were initially skipped intentionally, since I wasn't sure if they belong in cross-session memory which is intended for things like knowledge distillation and learning.

Tool results like the weather API example you quoted are usually session-local. If they matter later, the model typically includes them in later events, which the session summary already captures. Dumping every function response will inflate the event list and make summarization harder, or flood memory with low-quality entries and dilute search quality.

This is why I left them out, but I'm open to adding this if you can make a case for it.

[yashrajshuklaaa]

@supreme-gg-gg Fair concerns. On "the model restates it later" imo that's not reliable, when it acts on a result it usually just summarizes in its own words instead of repeating exact values (IDs, numbers), so those still get lost.
On volume/dilution : what if I only extract it when there's no later text event covering the same tool call, plus a length cap? Should cut down the low quality/duplicate entries while still keeping results that would otherwise be lost. Can push that if ur good with the approach.