feat: 添加 sensitive-logs feature flag 控制敏感日志输出

[BenedictKing]

动机

生产环境中 tracing::debug 输出完整 Kiro 请求体可能泄露用户对话内容。

实现

• 在 Cargo.toml 中添加 sensitive-logs feature flag
• 默认不输出完整请求体（仅记录字节数）
• 启用 feature 后才输出完整内容

# 调试构建
cargo build --features sensitive-logs

改动范围

• Cargo.toml: 添加 feature 定义
• src/anthropic/handlers.rs: 2 处请求体日志改为条件编译

[hank9999]

...? 各家debug日志都是输出完整请求内容的吧, 这样改了 开debug还要重新编译啊

[hank9999]

核心问题

tracing::debug! 本身就是 debug 级别日志。在生产环境中，除非明确设置
RUST_LOG=debug，否则这些日志根本不会输出。也就是说，所谓的"敏感信息泄露"场景，只在开发者主动开启 debug 日志时才会发生。

这个 PR 的逻辑矛盾

• 如果你在生产环境开了 RUST_LOG=debug，说明你本来就是要看详细调试信息的，此时"泄露"是预期行为
• 如果你没开 debug 日志，这两行 tracing::debug! 从一开始就不会执行

引入了新的问题

用 feature flag 解决的是编译时问题，但实际上这是运行时关注点。如果生产环境出了问题需要临时开启详细日志来排查，现在必须重新编译才能做
到，实用性大打折扣。

正确的做法

如果真的担心敏感信息，应该：

1. 在生产部署时用 RUST_LOG=info 控制日志级别（运行时配置，无需重编）
2. 或者把这两行改成 tracing::trace!（比 debug 更低级别），约定 trace 级别才含敏感内容

[BenedictKing]

这个我不太确定通用的做法是什么，这是claude给我的方案，我觉得还行就用了

原则上是发布版本不应该包含输出用户输入输出的行为，但是我又想自己测试的时候能追溯问题，所以采取这个方案