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

**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 `/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.