feat: add orbit_use_legacy_tools FF to gate legacy Orbit tool execution

What does this MR do and why?

Adds orbit_use_legacy_tools feature flag (kill-switch, default enabled) to gate legacy Orbit tools (query_graph, get_graph_schema, get_graph_status) in three paths that orbit_mcp_command_tools does not cover:

1. MCP execution (tools/call) — legacy tools were callable even when hidden from tools/list
2. AI Catalog picker — legacy tools were always selectable by custom agent authors
3. DWS pre-approved tools — legacy tools were always pre-approved/injected

When disabled, legacy tools become genuinely unreachable. When enabled (default), behavior is unchanged.

Notes

• The flag is defined as an ops kill-switch (default enabled). gitlab_com_derisk cannot be default_enabled: true, and a default-on kill-switch is exactly the ops type.
• get_graph_status is executable but never advertised by tools/list; it is covered via a new ToolCatalog::ALL_LEGACY_TOOL_NAMES constant.
• The AI Catalog picker (orbit_tool_names) is a global/class-level method, so it gates on the instance-wide rollout state (:instance actor). Execution and DWS paths use the per-user actor.

Edge case: discovery vs. execution divergence

When orbit_use_legacy_tools=false and orbit_mcp_command_tools=false, tools/list still advertises the legacy tools (discovery is gated only by orbit_mcp_command_tools) while tools/call rejects them with "Unknown tool". This is acceptable: the two flags address different concerns, and this combination is unlikely in practice since the intended rollout is command-tools-on. The deprecation switch deliberately makes execution the hard boundary rather than relying on discovery being hidden.

Relates to https://gitlab.com/dgruzd/tasks/-/work_items/2791