What would you like to be added?

Remove the dynamic slash command translation feature recently added in #3871. Concretely:

• Drop the general.dynamicCommandTranslation setting.
• Remove the runtime translation service and its call sites in the slash command processor, the non-interactive CLI commands, and the language command.
• Keep the human-authored built-in locale coverage from the same PR — that part is valuable and should stay.

A better long-term approach (locale-keyed description fields declared at the source, e.g. in the MCP prompt manifest or skill frontmatter) is mentioned at the bottom as context, but is intentionally out of scope here. This issue is about removing the current implementation, not proposing a replacement.

Why is this needed?

The feature ships disabled by default, but the implementation is on the hot path and has trade-offs that are hard to justify for an opt-in cosmetic improvement:

• Recurring model call. Every opted-in user pays a translation call on cold load, language switch, and command-set changes. For paid APIs or slow models, that's latency and tokens spent on UI text the user reads once.
• Non-deterministic output. Terse imperative descriptions are exactly where LLM translation drifts in register and wording across runs. Two startups can produce two different menus.
• Opaque quality. A user can't tell when a translation is wrong unless they speak both languages — at which point they didn't need the feature.
• Still half-localized. Command names remain English (e.g. /my-mcp-prompt), so translating only the description leaves the menu mixed-language anyway.
• Default-off. The author shipped it disabled, which itself signals low confidence in the trade-off.

Beyond the design concerns, a feature like this — adding a new setting, a new service, and a new runtime model call across both interactive and non-interactive paths — would benefit from a design discussion before landing. That didn't happen here. Reverting now, while almost no users are likely to have opted in (the setting is days old and disabled by default), is cheap. Reverting later, after users have built workflows around it, is not.

Additional context

• Related PR: feat(cli): core built-in i18n coverage #3871 (feat(cli): core built-in i18n coverage). The PR bundled two changes: (1) built-in locale coverage — keep, and (2) the dynamic-command LLM translation path — revert.
• Related setting: general.dynamicCommandTranslation (default false).
• Out of scope but worth noting for future work: the underlying problem (dynamic command descriptions are usually English while built-ins are localized) is real. A reasonable shape for a future solution is locale-keyed description fields at the source — e.g. a default description plus optional translations declared in the MCP prompt manifest or skill frontmatter, with fallback to the default when no match exists. No runtime model call, deterministic output, translator-controlled quality. Filing that as a follow-up makes sense once this revert lands.