[Refactor] 合并重复的 Starter 与 AutoConfiguration 发布层，精简扩展模块 #41

问题与证据

基于 Extensions 495414b7 的模块盘点，73 个 reactor 项目中有 20 个 starter 没有 src/main Java 实现。空 starter 本身是合理的依赖入口，问题在于多组入口仅转引一个专用 autoconfigure，后者又固定依赖对应实现，形成实现 → autoconfigure → starter 三层发布链，但没有体现独立装配复用需求。

例如 starters/argi-starter-vector-store-tair/pom.xml 依赖 argi-autoconfigure-vector-store-tair 和 argi-tair-store；autoconfigure 本身也依赖 argi-tair-store，仅含 3 个配置/属性类。其他向量后端、部分聊天记忆、Nacos Prompt 也存在同类结构。

建议方案

• 按能力逐对核实消费者与依赖图，将只服务一个入口的 autoconfigure 实现、属性元数据和 AutoConfiguration.imports 合入对应 starter。
• 保留非 Spring Boot 实现模块，避免直接使用实现时被迫引入 Boot。不同数据库、向量后端仍独立发布，避免引入全部 SDK。
• 有多个入口消费者或明确需要独立装配的 autoconfigure 可以保留；MCP gateway/router 等额外组合 Web、安全依赖的入口须单独检查，不能机械套用。
• 新坐标结构确定后统一 BOM、文档、示例和兼容门禁。逐组迁移，不一次性删除全部 20 个入口。

收益与替代方案

收益是减少重复 POM、BOM 条目、发布及兼容矩阵维护；不承诺通过少几个模块显著提升运行性能。替代方案是保留三层并通过公共构建模板降低重复；若独立 autoconfigure 确有复用，应优先采用替代方案。

兼容与验收

• 输出迁移前后 artifact/依赖/消费者矩阵，量化实际减少的发布单元。
• 保持配置 key、默认值、条件装配、用户 Bean 覆盖行为以及可选 SDK 边界；迁移期间避免重复自动装配。
• 对已发布坐标提供限期转发 POM 或明确的破坏性版本迁移说明，并解释适用范围。
• 验证单后端 starter 启动、禁用、缺类、用户覆盖、多个 starter 共存及最终发布依赖闭包。

关联：#30；此项处理发布层冗余，不替代 #33 的 Prompt 命名或 #34 的记忆契约职责梳理。