来自 #130 的架构级评审建议。不阻塞合入，仅供参考是否有更好的架构解法。
💡 [建议 · 资源] redact 中 json.Marshal 可能改变字段顺序和值表示 service/ingesthook/filter.go:101
问题根因：redact 先 json.Unmarshal 到 map[string]json.RawMessage，修改敏感字段后再 json.Marshal。Go 的 json.Marshal 对 map 按 key 字典序输出，这会改变原始 JSON 中的字段顺序。虽然 JSON 规范不保证字段顺序，但某些客户端可能依赖顺序（例如签名校验、增量 diff、调试日志）。此外，json.Marshal 会对一些数值格式做规范化（如 0.01 保持 0.01 但某些浮点数格式会变），虽然不改变语义值，但改变了表示。
为什么低级解法不够：这不是一个正确性 bug（JSON 规范不要求顺序），但作为通用中间件钩子，静默改变字段顺序可能被下游视为「篡改」——应记录为行为约定。
架构级方案：在文档中明确声明「钩子会对 JSON value 做反序列化→修改→重序列化，可能改变字段顺序和值格式化。不要求保留顺序的下游可安全使用」。如果未来需要保留原始 JSON 格式，可以使用字节级替换（扫描 JSON token 流，只替换命中的 key+value 对，不重新 marshall）。
代价/收益：字节级替换更复杂且脆弱（需要处理嵌套、转义等边界），当前方案简洁且正确，添加文档约束即可。
💡 [建议 · 资源] redact 中 json.Marshal 可能改变字段顺序和值表示
service/ingesthook/filter.go:101问题根因：
redact先 json.Unmarshal 到map[string]json.RawMessage，修改敏感字段后再 json.Marshal。Go 的json.Marshal对 map 按 key 字典序输出，这会改变原始 JSON 中的字段顺序。虽然 JSON 规范不保证字段顺序，但某些客户端可能依赖顺序（例如签名校验、增量 diff、调试日志）。此外，json.Marshal会对一些数值格式做规范化（如0.01保持0.01但某些浮点数格式会变），虽然不改变语义值，但改变了表示。为什么低级解法不够：这不是一个正确性 bug（JSON 规范不要求顺序），但作为通用中间件钩子，静默改变字段顺序可能被下游视为「篡改」——应记录为行为约定。
架构级方案：在文档中明确声明「钩子会对 JSON value 做反序列化→修改→重序列化，可能改变字段顺序和值格式化。不要求保留顺序的下游可安全使用」。如果未来需要保留原始 JSON 格式，可以使用字节级替换（扫描 JSON token 流，只替换命中的 key+value 对，不重新 marshall）。
代价/收益：字节级替换更复杂且脆弱（需要处理嵌套、转义等边界），当前方案简洁且正确，添加文档约束即可。