[Bug]: fix(handler): _search 的 k 参数未做类型校验，null/非数值输入触发 TypeError 返回 500

[openjiuwen-collaboration-bot]

Checklist

• 我已经搜索过相关问题，但没有得到预期的帮助。
• 最新版本中该错误尚未修复。
• 请注意，如果您提交的Bug描述缺少相应的环境信息和最小可复现的demo，我们将很难复现和解决该问题，从而降低收到反馈的可能性，甚至该问题将被关闭。

🐞 问题详细描述

问题详细描述：

jiuwen_memory_entry/core/handler.py 的 _search 处理函数中，top_k 参数直接强转：
top_k=int(payload.get("k", 10))
（第 651 行，mem2.0 分支 5cc2f6c）

缺陷表现：

1. k 传 null：payload.get("k", 10) 因 key 存在返回 None（默认值不生效），int(None) 抛 TypeError；
2. k 传非数值字符串（如 "abc"）：int("abc") 抛 ValueError；
3. 两种情况抛出的异常均非 AgentMemoryError 体系，被 dispatch 顶层 except Exception 捕获后返回 500 InternalError，
   而同类畸形输入按契约应返回 400 ValidationError。

行为不一致对比：同文件 _list handler 对 limit 参数使用了 _parse_positive_int 校验（非法值抛 ValidationError 返回 400），
_search 的 k 参数未复用同一模式，属于明显的校验遗漏。

重现步骤：

1. 启动 HTTP 服务（mem2.0@5cc2f6c）；
2. POST /search，请求体 {"query": "test", "k": null}；
3. 观察响应码为 500，期望 400；
4. 换 {"query": "test", "k": "abc"}，同样 500。

期望结果：

• k=null 或非法值时返回 400 ValidationError 与明确错误信息；
• k 合法时行为不变；不传 k 时默认值仍为 10。

修复建议：复用文件内已有的 _parse_positive_int 工具函数（_list 已在用），
改为 top_k=_parse_positive_int(payload.get("k"), name="k", default=10)，1 文件 +1-1 行。

详细的环境信息描述

详细的环境信息描述：

• 组件：JiuwenMemory agent-memory，mem2.0 分支，基线提交 5cc2f6c
• OS：Windows 11 x64（问题为纯应用层逻辑缺陷，与操作系统无关，Linux/macOS 同样复现）
• Python：3.13.x（项目要求 >=3.11，与 Python 小版本无关）
• 涉及文件与行号：jiuwen_memory_entry/core/handler.py 第 651 行（_search 函数内 top_k=int(payload.get("k", 10))）；
  对比参照：同文件 _list 函数约第 684 行 limit 参数已正确使用 _parse_positive_int
• 触发入口：HTTP /search、CLI search、MCP search 三个入口共用该 handler，全部受影响
• 依赖情况：修复复用文件内已有 _parse_positive_int 函数，不新增任何依赖
• 触发条件：请求体 k 字段传 null 或非数值即可触发，无需特定存储后端或配置

其他辅助信息

版本信息

感谢您的贡献 🎉!