Make /api/s resilient to source fetch failures (return empty list when no cache)

[fanrenaz]

背景 / Background

中文：部分源（例如 FreeBuf）在当前环境会对抓取请求返回 405 Not Allowed，导致返回值直接变成 500。在 MCP/Agent 场景里，单个源 500 会让工具调用失败，进而中断整次 agent 执行。

English: Some sources (e.g., FreeBuf) respond with 405 Not Allowed in our environment, which makes return 500. In MCP/Agent flows, a single source returning 500 can fail the tool call and break the entire agent run.

改动 / Change

中文：更新 [index.ts]：当拉取 [gettersid]id 失败时
有缓存：保持原逻辑，返回缓存（status: "cache"）。
无缓存：不再抛出错误导致 500；记录错误日志并返回一个合法的 [SourceResponse]，其中 [items: []]（status: "success"）。

English: Updated [index.ts]. When [gettersid]id fails:
If cache exists: keep existing behavior and return cached data ([status: "cache"].
If no cache: do not throw and produce a 500; log the error and return a valid [SourceResponse] with [items: []]([status: "success"].

收益 / Benefits

中文：单个源异常不再拖垮 /api/s，上层 MCP/Agent 调用更稳，返回结构保持一致。

English: A single broken source no longer brings down /api/s; MCP/Agent calls become more reliable and the response shape stays consistent.

验证 / Verification

中文：curl http://localhost:4444/api/s?id=freebuf
预期：返回 200，body 中 [items]为空数组（而不是 500）。

English: curl http://localhost:4444/api/s?id=freebuf
Expected: returns 200 with [items: []] (instead of 500).

[bruceblink]

你有没有想过，我是故意不做错误和异常处理的，如果你想用这些API应该在应用层做异常处理，而不是指望这个底层库把错误处理做了，如果我们在API底层就把错误都处理了，返回空数组，应用就会认为这个API的调用是成功的，实际上呢调用是失败的。这么做是不利于调试，不利于错误排查的。正确使用这些API的方式是封装一个http请求的客户端，然后在这个客户端中统一处理错误，转换请求失败的API返回空的数组，而不是让我们在底层就吞掉所有错误。