Wire context summarizer into hunter loop

[whatever]

Summary

• Wire ContextSummarizer into NativeHunter's step loop so deep hunts don't blow the context window
• Simplify the summarizer: keep all tool calls and tool results verbatim, only compress plain assistant/user prose
• Preserve flag-bearing messages unconditionally
• Output shape after summarization: [summary_ChatMessage, ...preserved_tool_msgs, ...recent_30%]

Problem

The hunter's own achat loop bypasses the agent runtime's summarization. Long hunts (~150k+ tokens) hit the context ceiling and fail. The existing ContextSummarizer was already in the codebase but wasn't wired into this path.

Approach

Minimal — no new classes, no config objects. The summarizer now has one simple rule: if a message has tool_calls or is a tool_response, keep it. Everything else in the old 70% window gets LLM-summarized into a single ChatMessage("system", ...).

Test plan

• pytest tests/test_memory.py — 32/32 passing
• Run a deep sourcehunt and confirm summarization fires at ~120k estimated tokens
• Verify preserved tool call history remains accessible to the hunter after compression

[whatever]

can confirm that this still finds things at a lower cost:

"On 32-bit platforms, jvp_string_alloc() has a size_t overflow in the allocation size computation `sizeof(jvp_string) + size + 1`. When jvp_string_append() computes `allocsz = (currlen + len) * 2` with large strings (total near INT_MAX), allocsz can be up to 4294967292. Passing this to jvp_string_alloc causes `sizeof(jvp_string) + 4294967292 + 1` to wrap around 32-bit size_t (e.g., to 13 bytes). The subsequent memcpy of ~2GB into the tiny allocation causes a heap buffer overflow.\n\nThe vulnerability is reachable cross-file: builtin.c's binop_plus() calls jv_string_concat() (jv.c) when adding two user-controlled strings. The INT_MAX check in jvp_string_append (line 1181) only validates currlen + len < INT_MAX, but doesn't prevent the allocsz * 2 result from overflowing size_t on 32-bit platforms when passed to jvp_string_alloc.\n\nAttack scenario: On 32-bit jq builds, concatenating two strings each ~1GB in size (via `. + .` or `* N` on a large string) triggers the overflow."
"On 32-bit platforms, jvp_array_alloc() has a size_t overflow in `sizeof(jvp_array) + sizeof(jv) * size`. The array index bound check in jv_array_set (line 1020) limits idx to INT_MAX >> 2 = 536870911, but ARRAY_SIZE_ROUND_UP can produce sizes up to ~805M. On 32-bit platforms with sizeof(jv)=12, `sizeof(jv) * 805306368 = 9663676416` overflows 32-bit size_t, causing a tiny allocation followed by writes to elements[] that overflow the heap buffer.\n\nCross-file aspect: jv_parse.c and jv_aux.c call jv_array_set/jv_array_append (in jv.c) with user-controlled indices. The index validation in jv_array_set is designed for 64-bit but insufficient for 32-bit platforms where the allocation arithmetic overflows."