feat(canvas): segment-skill 绑定链路（bindSkillToSegment 等）—— 契约已签、缺后端实现

## 背景

同 #1464/#1465 的调查结论：`bindSkillToSegment` / `instantiateForSegment` /
`runSegmentSkill` / `listSegmentSkills` 在契约里已签核，domain 层已有
`apps/api/src/domain/canvas/segment-binding.ts` 可复用，**但没有 controller
路由、没有 application use case**。

前端 `apps/web/components/canvas/segment-binding.tsx`（蓝本设计器·议程环节绑定）
是纯 mock 原型——**不只是绑定动作是 mock，连议程环节列表本身
（`SEGMENT_BINDINGS`）都来自 `lib/mock/canvas`，不是真实项目数据**。这比
`ai-draft-panel`/`knowledge-backflow` 两个多一层：需要先确认"蓝本设计阶段的
议程环节"这个真实数据源在哪（是否已有 `/blueprint` 或 `/tpl` 域的真实端点可以
喂给这一屏，还是这一屏本身也没有对应的读路径）。

## ⚠️ 实现前必须先确认的点（不是 KNOWN_CONTRACT_GAPS，是数据源缺口）

- 「蓝本设计阶段」（未实例化到具体项目前）的议程环节列表，真实来源是哪个契约
操作？还是这个概念本身在契约里也还没有对应的读路径——如果是后者，这不是
"缺路由"，是缺一个更基础的读操作，需要先勘探清楚再判断是否需要新契约面。
- 已有 `template-apply-dialog.tsx`（`template-admin.tsx` 里"使用"按钮）是
**项目内、已实例化**环节的模板绑定，走的是 `bindTemplateToSegment`（已真实
接线，见 #988 附带工作）。本 issue 的 `segment-binding.tsx` 是**蓝本设计时**
的绑定，是不同的场景，不要混着改。

## 任务

1. 先勘探「蓝本设计阶段议程环节」的真实数据源是否存在，写清楚结论再动手。
2. 若数据源已存在：后端补 skill 绑定的 use case + 路由，前端去 mock。
3. 若数据源不存在：这本身可能是一个更大的缺口，需要单独报告，不要在本 issue
里顺手发明一个新读操作。

## 验收

- 视勘探结论而定，最低限度：写清楚"蓝本议程环节数据源是否存在"这个结论，
避免下一个人重新踩一遍同样的坑。

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Start by tracing apps/web/components/canvas/segment-binding.tsx and its SEGMENT_BINDINGS mock, then inspect apps/api/src/domain/canvas/segment-binding.ts and existing blueprint or tpl entry points. Confirm whether a real source exists for pre-instantiation agenda segments. Done means documenting that conclusion; only if the source exists should the skill use case, routes, and frontend mock replacement proceed.

Written by the indexing model from the issue text.