[P2][types] 将 Default 与配置序列化约束下放到实际需要的方法 #94

问题与影响

Builder 整个方法集合要求 S: Default。即使用户已经构造状态并调用 .state(value)，也必须为连接池或其他不能合理默认构造的状态实现 Default。
ConfigWrapper、GotchaContext 在类型定义上携带 Deserialize/Serialize/Default 约束，继续传播到消息与计划任务代码；这些运行时组件主要只是保存、克隆或读取已经加载的配置。

代码位置

静态审查确认：

• gotcha/src/builder.rs:118
• gotcha/src/builder.rs:203
• gotcha/src/config.rs:39
• gotcha/src/lib.rs:119
• gotcha/src/message.rs:44
• gotcha/src/task.rs:54

调整方向

运行时容器保留真正需要的约束；serde 约束放在加载/序列化实现上，Default 放在选择默认构造的方法上。显式状态注入应有不依赖 Default 的入口，避免为满足框架而写虚假的默认状态。

验收标准

• Clone + Send + Sync 但不实现 Default 的状态可以显式注入并正常服务请求。
• 不需要配置文件加载的显式上下文不被无关 serde/Default 约束阻止。
• 默认构造的便捷 API 保留，并在实际边界声明 Default。
• 保留必要的 Send/Sync 与生命周期保证。
• 用外部消费者的编译测试验证，不只测试仓库内示例。
• 说明公共 API 和宏生成代码的兼容变化。

相关：#66 聚焦类型书写体验，本 issue 聚焦不必要的能力约束。

实现与验证

PR #110，head ea9ec6b6552e3c1394d6b54a2e6b6bc6725bb522，已合入。新增 Gotcha::from_state(value) / Gotcha::from_context(context)，运行时容器、提取宏、消息和任务移除加载约束；默认构造入口保留延迟初始化与原有配置优先级/错误处理。

GotchaApp::Config 只保留运行时约束；泛型调用 config() / run() 时现在需显式声明 Config: DeserializeOwned，详细说明见迁移文档。GotchaConfig 保留原有兼容能力集合，框架运行时不再依赖它。

本地 gotcha 默认/全功能完整测试（含文档示例）、宏测试、workspace Clippy、格式和 diff 检查均通过。外部消费者验证无 Default/serde 的 context、HTTP 提取和 Message、任务注册、所有 builder 启动入口的 Send future、独立读写配置能力；原有配置来源与组合测试也通过。11 项 GitHub CI 检查全部通过。

PR #110 已于 2026-09-14T05:11:24Z 合入，merge commit f33811e9b1548f0f57e58922afb2bfc8925c0953。