[FEATURE] Add a Strands web search tool under the existing integrations pattern

[sundargthb]

Is your feature request related to a problem? Please describe.

There is no way to give a Strands agent AgentCore Web Search, while strands-agents/tools already ships three third-party search tools: tavily.py, exa.py and bright_data.py. So a developer already on Bedrock signs up with a separate search vendor and manages a second key and a second bill for a capability the platform already has.

There is also a recurring confusion to clear up. The plugin at src/bedrock_agentcore/gateway/integrations/strands/plugins/agentcore_tool_search/ is regularly mistaken for a web search integration. It does semantic tool discovery over a gateway's registered tools using x_amz_bedrock_agentcore_search, which is a different feature.

Describe the solution you'd like

A Strands tool for web search in this repo, following the <capability>/integrations/strands/ layout already used here:

• src/bedrock_agentcore/gateway/integrations/strands/plugins/agentcore_tool_search/
• src/bedrock_agentcore/memory/integrations/strands/
• src/bedrock_agentcore/evaluation/integrations/strands_agents_evals/

The packaging is already in place. pyproject.toml declares strands-agents = ["strands-agents>=1.46.0", "mcp>=1.23.0,<2.0.0"], so this installs through the existing pip install 'bedrock-agentcore[strands-agents]' path with no new dependency and no new extra.

It should be a thin @tool over the WebSearchClient proposed in #654 rather than wiring up Gateway and MCP itself, so there is one place that knows how a search is reached.

Describe alternatives you've considered

Adding it to strands-agents/tools next to tavily.py and exa.py. Two reasons against it.

First, version coupling. strands-agents/tools already has an open bug from this exact pattern: strands-agents/tools#551, where the agent-core-browser extra pins bedrock-agentcore<1.2.0 and will not resolve against a current SDK. bedrock-agentcore is at 1.22.0. An AgentCore tool living in another project's release cycle inherits that class of failure, whereas here the version relationship is internal.

Second, direction of travel. strands-agents/tools#363 is pushing tool-specific dependencies out of that package because it is 233MB unzipped, and the Strands roadmap is separately moving vended tools into their SDK under strands-agents/harness-sdk#3234.

Nothing here requires a change in a Strands repo. This repo consumes strands as a dependency, so it ships on this project's own release cadence.

Additional context

Depends on #654 for the client. The connector target itself is connectorId: "web-search" with the WebSearch operation, which is what the create_web_search_target() helper in that issue would build.