fix: Responses tool continuations rescan the entire session history to recover tool names

[sam-saffron-jarvis]

What changed

• Changed populateResponsesToolResultNames to prefer reverse-paged store lookups when the session store supports session.MessagesDescendingPager.
• The lookup now scans recent persisted messages in descending sequence order and stops as soon as all missing tool-call IDs are resolved.
• Kept the existing full-history GetMessages fallback for stores that do not implement the optional reverse pager.
• Added a regression test covering the reverse-paged path and verifying it resolves an older tool call without falling back to full-history loading.

Why this is high-value

Responses follow-up requests that contain only function_call_output items often arrive without tool names in the current payload, so the server has to recover names from prior tool-call messages.

Before this change, persisted continuations could call GetMessages(ctx, sessionID, 0, 0) and deserialize the entire transcript just to recover one or a few tool names. On long-lived, tool-heavy sessions that turns a hot follow-up request into O(full transcript) DB I/O and JSON decoding.

After this change, SQLite/logging-backed stores can read only the newest tail pages and stop early once the needed call IDs are found. That reduces total rows read, JSON deserialization work, peak allocations, and continuation latency, especially when the relevant tool call is near the end of a long session.

Validation

• gofmt -w cmd/serve_handlers_responses.go cmd/serve_test.go
• go build ./...
• go test ./...
• Added TestPopulateResponsesToolResultNames_UsesReversePagedStoreLookup to verify reverse paging is used and full-history GetMessages is not called when the pager capability is available.