Decide flattenedCommandNaming placement: top-level key vs featureOptions (before next major)

[dyoshikawa]

Background

Item 6 of #2323 (the PR #2314 review follow-ups) raised a design question that is intentionally not resolved by the mechanical follow-up PR: flattenedCommandNaming was added as a top-level config key rather than under the existing per-target/per-feature featureOptions mechanism.

Details

• Top-level placement has precedent (simulateCommands is top-level), but featureOptions would give per-tool control (e.g. "path" for Cursor only) and automatic propagation to every code path that already consumes featureOptions, which would have prevented the convert-path wiring gap fixed in Follow-ups from PR #2314 review: flattenedCommandNaming convert wiring, docs wording, and tests #2323 item 1.
• Moving the key later is a breaking config change, so the shape should be decided before it ossifies — ideally before the next major release.

Solution / Next Steps

Decide one of:

1. Keep top-level (status quo): document it as a deliberate global switch and close this issue.
2. Move under featureOptions: plan the deprecation — accept both locations for one major cycle with a warning on the top-level key, then remove it.

No code change until the decision is made.