Use the existing options field for a tool setting's fixed values, not a second choices field

[peteski22]

Problem

The deployment settings API already has a way to say that a string setting takes one of a fixed set of values:

• _Spec.options and settable_options() in services/runtime_settings_service.py,
• returned as options on ConfigField in api/routes/settings.py,
• rendered as a FilterSelect by web/src/features/settings/SettingsPage.tsx.

#1366 added a second way, for tool settings:

• _ToolSpec.choices and field_choices() in services/tool_settings_service.py,
• returned as choices on ToolSettingField in api/routes/tool_settings.py,
• rendered by a new ChoiceRow in web/src/features/tools/ToolSettingRows.tsx, which also wraps FilterSelect and adds display labels.

So the API has two field names for one idea. choices has not shipped in a release yet.

Proposal

Call it options in the tool settings spec, helper and response model, so both settings APIs use one field name. The dashboard reads options for both, and keeps the labels the Tools page shows.

The two spec classes, _Spec and _ToolSpec, existed before #1366. Merging them is not part of this issue.

Acceptance

• ToolSettingField has options and no choices, in the code and in docs/public/openapi.json.
• The Tools page still shows the executor setting as a select, with its labels.
• make openapi-check, make postman-check and the dashboard client drift check pass.

Part of #1470.