azd ai agent init: azure_ai_search tool resource needs to auto-pair a storage dependent resource

## Summary

When an agent `agent.manifest.yaml` declares `kind: tool` / `id: azure_ai_search` and the user runs `azd ai agent init`, the generated `azure.yaml` requests only the `azure_ai_search` dependent resource. `azd provision` against the [`azd-ai-starter-basic`](https://github.com/Azure-Samples/azd-ai-starter-basic) template then fails because the starter's `azure_ai_search.bicep` requires a co-provisioned storage account, but `init.go` does not auto-pair them.

## Root cause

[`init.go`](https://github.com/Azure/azure-dev/blob/main/cli/azd/extensions/azure.ai.agents/internal/cmd/init.go) only recognizes two tool ids when scanning the manifest's `resources:` array for things to add to `azure.yaml` `resources:` (which becomes `AI_PROJECT_DEPENDENT_RESOURCES` at provision time):

```go
if toolResource.Id == "bing_grounding" || toolResource.Id == "azure_ai_search" {
// prompt for connection name
resourceDetails = append(resourceDetails, project.Resource{
Resource: toolResource.Id,
ConnectionName: resp.Value,
})
}
```

There is no notion of `storage` here, and no logic that auto-adds `storage` when `azure_ai_search` is selected, even though the matching starter bicep requires it. Result: a manifest that declares search alone is silently incomplete and the failure only surfaces during provision.

## Repro

1. Author an `agent.manifest.yaml` with `kind: tool` / `id: azure_ai_search` (no storage entry, no sample-local infra).
2. `azd ai agent init -m ` (accept the prompt for the search connection name).
3. `azd provision` against the default `azd-ai-starter-basic` template.
4. Bicep deployment of the `azure-ai-search` module fails resolving the `existing` Storage Account reference because `storageAccountResourceId` is empty.

## Why it matters

Hosted-agent samples are being migrated to the manifest-only flow (drop sample-local bicep, lean on the starter). The pattern works cleanly for chat/embedding models and for `bing_grounding`. It is the only RAG-relevant tool kind currently broken end-to-end.

Triggering case: [microsoft-foundry/foundry-samples-pr#283](https://github.com/microsoft-foundry/foundry-samples-pr/pull/283) (Azure AI Search RAG sample for .NET Agent Framework). The README there documents a manual `azure.yaml` edit as a workaround:

```yaml
services:
:
config:
resources:
- resource: azure_ai_search
connectionName: search
- resource: storage
connectionName: storage
```

## Proposed fix

Pair them in `init.go`: when the user selects `azure_ai_search`, append a `storage` `project.Resource` entry as well (with a deterministic default connection name) so the generated `azure.yaml` matches the starter's contract. Could be unconditional, or gated by a follow-up confirmation prompt for users who already have storage wired some other way.

A complementary upstream fix on the starter (make `storageAccountResourceId` optional in `azure_ai_search.bicep`) is tracked at [Azure-Samples/azd-ai-starter-basic#62](https://github.com/Azure-Samples/azd-ai-starter-basic/issues/62), but the more user-friendly fix is in the extension because today the manifest is the only contract a sample author touches.

Happy to send a PR if the direction is agreed.

## Related

- [Azure-Samples/azd-ai-starter-basic#62](https://github.com/Azure-Samples/azd-ai-starter-basic/issues/62) - corresponding starter-side gap
- [microsoft-foundry/foundry-samples-pr#283](https://github.com/microsoft-foundry/foundry-samples-pr/pull/283) - sample blocked on this

Start in cli/azd/extensions/azure.ai.agents/internal/cmd/init.go, where the manifest resources are scanned and azure.yaml resources are assembled. Reproduce with an azure_ai_search-only manifest and azd ai agent init; done means the generated azure.yaml includes both azure_ai_search and a storage resource so azd provision matches the starter contract.

Written by the indexing model from the issue text.