Closes #56778

## Problem

The agent-profile tool configuration lists every built-in tool from
`agent::ALL_TOOL_NAMES`, filtering only by provider support
(`crates/agent_ui/src/agent_configuration/manage_profiles_modal.rs`).
But `Thread::enabled_tools` additionally drops feature-flag-gated tools
before they reach the model — the LSP tools (`go_to_definition`,
`find_references`, `get_code_actions`, `apply_code_action`) behind
`LspToolFeatureFlag`, `rename_symbol` behind `RenameToolFeatureFlag`,
and `create_thread` / `list_agents_and_models` / `update_plan` /
`update_title` behind their own flags.

The result: when a flag is off, a user can enable the tool in a profile,
but the agent never receives it. The picker and the runtime gate
disagreed.

## Fix

Extract the feature-flag gating into a single shared predicate,
`agent::tool_feature_flag_enabled`, and route **both**
`Thread::enabled_tools` and the profile tool picker through it. The
configuration UI can no longer offer a tool the agent would silently
drop, and the two call sites can't drift apart. Also updated the "silent
drop gates" comment in `tools.rs` to document this third gate.

This matches the behavior requested in the issue (don't list tools that
can't be used). The alternative — showing them disabled with an
explanation — is also possible; happy to switch if preferred.

## Testing

- Added `lsp_tools_are_gated_by_their_feature_flag` in
`crates/agent/src/tools.rs`.
- `cargo test -p agent`, `cargo clippy -p agent`, and `cargo fmt` are
clean.
- (`agent_ui` doesn't build in my local environment due to an unrelated
`webrtc-sys` C++ toolchain issue; the `agent_ui` change is a one-line
filter addition mirroring the adjacent provider-support check — relying
on CI to confirm.)

Release Notes:

- Fixed feature-flag-gated tools (such as the LSP tools) being listed in
agent profile configuration when they could not actually be used by the
agent.

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>