crm_opportunity.forecast_category 的 best_case 在 zh 文档有三种写法：包里「最佳情况」，opportunities 写「最佳可能」，automation 写「最好情况」 #845

来源：#829（PR #842）实施时的越界发现。基线 origin/main = a501812。

与 #829 同一缺陷类（文档里的选项名与 src/translations/zh-CN.ts 不符），但落在隔壁那个选择列表上，所以 #842 没有顺手改 —— #829 的事实来源被明确限定为 crm_opportunity.stage 的七个选项。

包里 crm_opportunity.fields.forecast_category.options：

best_case 一个选项，zh 文档写出了三种说法：

• 「最佳情况」（对） —— sales/forecasting.zh-Han{s,t}.mdx:17,22,25、sales/index.zh-Han{s,t}.mdx:30、reference/glossary.zh-Han{s,t}.mdx:30、ai-copilot/sales-copilot.zh-Han{s,t}.mdx:94
• 「最佳可能」（错） —— sales/opportunities.zh-Han{s,t}.mdx:128,134，各 2 处共 4 处。两处都紧挨着 **承诺（Commit）** 这个写对了的同族选项，所以是同一句里一对一错
• 「最好情况」（错） —— administration/automation.zh-Han{s,t}.mdx:91

automation:91 同一行还有第二处：「管道、最好情况、承诺与赢单合计」描述的是 Forecast Snapshot 写进预测行的四个数，而 crm_forecast 的对应字段是 closed_amount，包里的 label 是「已成交金额」——「赢单合计」在包里零命中。

为什么值得单独扫一遍

sales/opportunities.zh-Han{s,t}.mdx 正是 #829 的锚点页，#842 已经在改它了却没动这四处 —— 因为它们是 forecast_category 而不是 stage，越界。但也正因为如此，这一族现在是「已知未修」，留着容易被当成扫漏。

「本季度待成交商机」这个视图的全部意义就是按预测类别筛选，读者按文档里的「最佳可能」去界面上的预测类别下拉里找，是找不到的。

复核：

grep -rn "最好情况\|最好情況\|最佳可能\|赢单合计\|贏單合計" content/docs/

Refs #802 #829 #842