refactor: 后端仓库层收口（A1：课程/产品/素材）+ 收进工作区既有对象化重构

本提交含两部分。第一部分是本轮工作；第二部分是此前一直留在工作区、
从未提交的对象化重构，与第一部分在文件上互相咬合（internal/repository
整个包都是未跟踪状态，且 api 层已有文件引用它），无法拆成两个可编译的提交。

一、仓库层收口 A1 批（本轮工作）

把 api 层手写的 store.DB 查询收进具名仓库方法，只给真正获益的对象做方法，
不机械包裹全量。本批迁移 22 处裸查询（courses.go 9 / media.go 12 / products.go 1），
新增方法：

- MediaFileRepo.ListByBind / ListForAudit / MarkExtracted
- KnowledgeChunkRepo.CountByMediaFile
- ProductRepo.GetVisibleByID

两条业务口径改由仓库单点持有，避免各处手写漂移：
「只有 approved 素材出现在课程详情」与「已停用产品不在课程详情露出」。

修掉两个真实缺陷：
- ProductRepo.GetByID 缺 Where 条件。此前 GET /api/products/{id} 对任意 id 都返回
  第一条产品、对不存在的 id 返回 200，且 PUT /api/products/{id} 会覆盖第一条产品
  —— 数据损坏级。全仓扫描确认这是唯一一处同型写法。
- ProductRepo.Delete 写 status="deleted"，而 DELETE 处理器文档与回包都声称
  "inactive"，接口在说谎；管理员用 status=all 拉列表会看到前端不认识的状态。
  已对齐为 inactive（与 CourseRepo.Delete 一致）。

删除 8 个零调用且列名不存在的死方法（一调即 SQL 报错）：
- media_file 上的 file_path / file_type / approval_status 三列并不存在，
  GetByPath / ListByType / UpdateStatus 全废
- knowledge_chunk 上的 space_id 列不存在（模型早已改为 knowledge_space_key），
  List / Total / ListBySpaceIDs / DeleteBySpace / SearchByVector 全废
取舍边界：能对当前 schema 跑通的死方法保留，跑不通的删或修。

CourseRepo.List 补齐 status=all 档（此前传给它会当作 status='all' 过滤出空列表）。
该方法此前零调用，现与产品列表语义对齐。

验证：go build ./... 与 go test ./... 全绿；另用真实 HTTP 请求验证 34 项
（课程 17 / 产品 3 / 素材 14），跑在数据库副本与独立 KB_DATA_DIR 上，
含 multipart 真上传 → 审批 → pdftotext 提取 → 分片入库的完整链路。

二、此前未提交的对象化重构（非本轮工作）

- 新增 internal/repository 仓库层、connectors、skills、specialists、xapps、jsonutil，
  model/task_record|task_run|task_artifact、api/task_runtime|action_definition|chat_message
- 删除 api/app_definition、connectors、my_app_center、notification、office_skill、
  export_docx|pptx|xlsx、official_account_* 等，随 XApp/Skill/Specialist/Connector
  可插拔打包方向（AR10/AR11）调整
- 资产目录归位：backend-go/knowledge_source → assets/knowledge/source、
  training_materials → assets/training/materials；README 内相对路径同步加深两级；
  deploy env 补 ASSET_ROOT_DIR 并改 KNOWLEDGE_SOURCE_DIR / TRAINING_MATERIALS_DIR
- 前端新增 skills/ specialists/ connectors/ xapps/ 目录与对应页面

验证：前端 npm run build 通过（7.26s）。

Co-Authored-By: Claude Code <noreply@anthropic.com>

docs/04_Backend/BE06_AI_Config_Credits_Module.md

@@ -12,7 +12,7 @@ pj034 的 AI 系统已演进为「多层、多公司、多租户」的完整运
 **移植范围（保留）**：
 1. AI 路由/Provider/密钥配置文件体系（`ai_config.json` + `ai_secrets.json`）——已落地
 2. Agent → 路由映射、默认路由、回退链（fallback）
-3. **按用户算力点计费**：每次 AI 调用按能力扣点 + 写调用日志
+3. **按用户算力点计费**：每次 AI 调用按用量类型扣点 + 写调用日志
 4. AI 配置管理 API（读/写/热重载/密钥状态）+ 用量查询 API
 5. 前端：AI 配置 UI + AI 用量看板 + 用户剩余点数展示
 
@@ -58,7 +58,7 @@ pj034 的 AI 系统已演进为「多层、多公司、多租户」的完整运
 | `company_id` | int | 公司维度 | ❌ 单公司，删除 |
 | `user_id` | int | 调用人 | ✅ |
 | `provider` | enum | provider | ✅ |
-| `capability` | enum | AI 能力 | ✅ |
+| `usage_kind` | enum | AI 用量类型 | ✅ |
 | `input_asset_id` / `output_asset_id` | int | 电商素材 | ❌ |
 | `ai_route_id` | str | AI 路由 ID | ✅ |
 | `model_id` | str | 模型 | ✅ |
@@ -78,7 +78,7 @@ pj034 的 AI 系统已演进为「多层、多公司、多租户」的完整运
 ### 3.2 扣点收口 `compute_credits`（pj034）
 
 ```python
-CAPABILITY_CREDITS = {
+USAGE_KIND_CREDITS = {
     AiCapability.TEXT_DIAGNOSE: 1,
     AiCapability.BG_REMOVE: 1,
     AiCapability.BG_REPLACE: 2,
@@ -88,17 +88,17 @@ CAPABILITY_CREDITS = {
     AiCapability.IMAGE_VALIDATE: 1,
 }
 
-def compute_credits(capability, billing_mode, status):
+def compute_credits(usage_kind, billing_mode, status):
     if status != SUCCESS or billing_mode != PLATFORM:
         return 0
-    return CAPABILITY_CREDITS.get(capability, 0)
+    return USAGE_KIND_CREDITS.get(usage_kind, 0)
 ```
 
 **核心规则**：只有「调用成功」才扣点；失败不扣点。扣点决策收口到 service 层，不在各端点散落判断。
 
 ### 3.3 计费聚合 API（pj034 `ai_billing.py`）
 
-`GET /data/ai-billing?days=30&group_by=month|capability|provider|month_capability`
+`GET /data/ai-billing?days=30&group_by=month|usage_kind|provider|month_usage_kind`
 
 返回 `{ summary: {total_calls, success_calls, failed_calls, total_credits_charged}, buckets: [...] }`。SQLite 下按月聚合走 Go 侧 group。
 
@@ -106,9 +106,9 @@ def compute_credits(capability, billing_mode, status):
 
 ## 4. pj0231 计费模型（精简）
 
-### 4.1 能力 → 点数（CAPABILITY_CREDITS）
+### 4.1 用量类型 → 点数（USAGE_KIND_CREDITS）
 
-| capability | 含义 | 点数 |
+| usage_kind | 含义 | 点数 |
 |-----------|------|------|
 | `ai_chat` | PathCoach 对话（每轮） | 1 |
 | `text_gen` | 快捷动作（情景演练/查佣金/产品对比） | 1 |
@@ -128,7 +128,7 @@ def compute_credits(capability, billing_mode, status):
 |------|------|------|
 | `id` | uint PK | |
 | `user_id` | uint index | 调用人 |
-| `capability` | str | ai_chat / text_gen / embed |
+| `usage_kind` | str | ai_chat / text_gen / embed |
 | `provider` | str | 实际命中的 provider |
 | `ai_route_id` | str | AI 路由 ID |
 | `model` | str | 模型名 |
@@ -159,7 +159,7 @@ def compute_credits(capability, billing_mode, status):
 
 | 方法 | 路径 | 说明 |
 |------|------|------|
-| GET | `/api/ai/usage?days=30&group_by=month` | 用量聚合（管理员 = 全量；员工 = 本人，后端按角色过滤） |
+| GET | `/api/ai/usage?days=30&group_by=month|usage_kind|provider` | 用量聚合（管理员 = 全量；员工 = 本人，后端按角色过滤） |
 | GET | `/api/ai/usage/users` | 管理员：按用户聚合的用量 + 剩余点数（充值入口数据源） |
 | GET | `/api/ai/me` | 员工：本人剩余点数 + 近 N 天用量 |
 
@@ -188,7 +188,7 @@ def compute_credits(capability, billing_mode, status):
 复刻 pj034 `AiUsage.vue` 的精简版：
 - 汇总卡：总调用 / 成功 / 失败 / 总消耗点数（去掉「¥ 花费」）
 - 时间窗切换：近 30 / 90 / 365 天
-- 分组明细：按月 / 按能力 / 按 provider
+- 分组明细：按月 / 按类型 / 按 provider
 - 管理员额外视角：按用户聚合（含剩余点数）
 
 菜单位置：知识管理下新增「AI 用量」（管理员）；员工入口放在 PathCoach 面板内（本人剩余点数 + 近 30 天用量）。
@@ -205,7 +205,7 @@ def compute_credits(capability, billing_mode, status):
 - [x] LLM 客户端 + 回退链（`GenerateWithFallback` 已实现，待接入 ChatMessage）
 - [x] `model/ai_call_log.go` + `model/user.go` 加 `ai_points`
 - [x] `store/db.go` AutoMigrate 加 `AiCallLog`
-- [x] `internal/ai/credits.go`：CAPABILITY_CREDITS + compute_credits + log_ai_call
+- [x] `internal/ai/credits.go`：`UsageKindCredits` + `ComputeCredits` + `LogCall`
 - [x] `internal/api/ai_chat.go`：ChatMessage/QuickAction 接入扣点 + 日志 + 回退链
 - [x] `internal/api/ai_admin.go`：AI 配置读/写/热重载/密钥状态
 - [x] `internal/api/ai_usage.go`：用量聚合 + 按用户聚合 + 本人剩余点数