ui: 工具标签表把 get_company_profile 写成 get_profile，真实工具回落到「获取数据」兜底、agent.tool.names.getProfile 文案不可达 #308

问题与复现

packages/ui/src/lib/agentPresentation.ts 的文件注释自称是 agent 展示层的「single source of truth」，且 hasSemanticToolLabel 的存在理由是「keeps fallbacks honest」。但 TOOL_LABEL_KEY 把公司概况工具写成了 get_profile：

const TOOL_LABEL_KEY: Readonly<Record<string, string>> = {
  get_quote: 'agent.tool.names.getQuote',
  ...
  get_profile: 'agent.tool.names.getProfile',   // ← 第 25 行
  analyze: 'agent.tool.names.analyze',
};

而仓库里真实注册的工具名是 get_company_profile：

• packages/shared/src/agent/finance-tool-registry.ts:11-31 的 FinanceToolName 联合类型共 20 个成员，含 get_company_profile，不含 get_profile；
• packages/shared/src/capabilities/manifests/company-profile.ts:15 声明 toolName: 'get_company_profile'；
• 对 packages/shared/src/capabilities/manifests/*.ts 的全部 toolName: 取值去重后正好 20 个，与 FinanceToolName 逐项一致。

全仓检索 get_profile（`.ts/.tsx` 全部生产代码）只有 2 处命中，都在本文件内部（:25 标签表、:40 分类表），没有任何生产者。

最小复现

import { semanticToolLabelKey, hasSemanticToolLabel } from './agentPresentation';

semanticToolLabelKey('get_company_profile');  // 实际 'agent.tool.names.other'  预期 'agent.tool.names.getProfile'
hasSemanticToolLabel('get_company_profile');  // 实际 false                      预期 true
hasSemanticToolLabel('get_profile');          // 实际 true                       预期 false

生产渲染路径（已回读源码确认）：运行事件 → packages/ui/src/atoms/runAtoms.ts 写入 toolCalls → components/agent/AgentPanel.tsx:300/304 → components/agent/ToolActivity.tsx:50 的 t(semanticToolLabelKey(toolCall.toolName))。因此用户看到的这一行标签是 Gather data / 获取数据，而不是 Company profile / 查看公司概况。

连带后果：一条文案成为死条目

两侧语言包里这条文案都已存在，却因为永远无法命中而不可达：

• packages/i18n/src/locales/en-US/agent.ts:63 → getProfile: 'Company profile'
• packages/i18n/src/locales/zh-CN/agent.ts:63 → getProfile: '查看公司概况'

这属于「稳定 id → 枚举表 → 解析器」这类缺陷里最常见的一种：表里有一条永远不会命中的条目，同时一个真实存在的 id 没有条目。

预期与修复方向

把 TOOL_LABEL_KEY 的 get_profile 更正为 get_company_profile，共 1 行。

判据是该条目的目标没有歧义：它指向的文案 getProfile 语义正是「公司概况」，与 company.profile 能力（manifests/company-profile.ts）一一对应；而 get_profile 这个 id 在全仓没有任何生产者，不可能是刻意保留的别名。

复现证据

• 环境：Windows 11 + Bun 1.4.2，基线 main 3a17eca6（LF 快照）
• bun test packages/ui/src/lib/agentPresentation.test.ts --isolate
  • 修复前：4 pass / 2 fail
    • Expected: "agent.tool.names.getProfile" / Received: "agent.tool.names.other"
    • Expected: false / Received: true
  • 修复后：6 pass / 0 fail
• bun test packages/ui --isolate：346 pass / 0 fail（63 files）
• bun run typecheck：core / i18n / shared / ui / electron 五个工作区全部 exit 0

上游 PR checks 工作流当前为 disabled_manually，新建 PR 不会产生 check run；以上均为 CI 等价命令的本地结果。

范围

• 只改 TOOL_LABEL_KEY（它有真实渲染消费方：ToolActivity.tsx:50、TraceInspector.tsx:223）。
• 刻意不改 同文件 :40 的 TOOL_CATEGORY：它虽然也带着同一个 get_profile 笔误，但 semanticToolCategory 当前没有生产消费方（全仓引用只有自身定义、自身单测，以及 lib/capabilityLabels.ts:9 的 re-export），本 PR 不引入无法验证的改动。
• 同一族但本次不改的条目，作为观察在此记录，方便后续一次性清理：
  • TOOL_LABEL_KEY 的 analyze：同样不对应任何已注册工具名，但没有证据表明它应当对应哪个 id；
  • TOOL_CATEGORY 的 get_depth / get_events：按命名疑似应为 get_market_depth / get_calendar_events，同样无消费方。
• 不涉及样式，不改变任何可见形状（仅把兜底文案换成既有译文）。