`azd` CLI support for adding/updating/maybe deleting things in azure.yaml

- [x] Make sure you've installed the latest version using [instructions](https://github.com/Azure/azure-dev?tab=readme-ov-file#installupgrade-azure-developer-cli)

**Output from `azd version`**

```
azd version 1.29.0 (commit fc06de978b9e9dc98a50ebb601a18b0f9f24071a) (stable)
```

**Describe the feature request**

azd can *deploy* a `host: staticwebapp` service, but has no code path that can *write* one into `azure.yaml`. The result is an asymmetry: azd fully supports Static Web Apps as a deployment target, yet a user (or a tool building on azd) can only get there by hand-authoring the `services:` entry.

Concretely, the two host types azd can scaffold are:

```go
// cli/azd/pkg/project/resources.go
ResourceTypeHostContainerApp ResourceType = "host.containerapp"
ResourceTypeHostAppService ResourceType = "host.appservice"
```

`azd add` offers only those two under "Which type of host?", and for existing resources the entire `host` namespace is skipped:

```go
// cli/azd/internal/cmd/add/add_select.go
if menu.Namespace == "host" || // host resources are not yet supported
```

`StaticWebAppTarget` appears only under `cli/azd/pkg/project` (the deploy side). It has no counterpart in `cli/azd/internal/repository` (init / `--from-code`) or `cli/azd/internal/cmd/add`, so no init or add mode can produce a Static Web Apps service entry.

**To Reproduce**

1. `azd init --minimal` in an empty directory. `azure.yaml` is created with a `name:` and no services.
2. `azd add` and choose "Host service".
3. Only Container Apps and App Service are offered. There is no way to add a Static Web App.
4. The only way to reach a working `azd deploy` for a Static Web App is to hand-write the `services:` entry.

**Expected behavior**

`azd add` offers Static Web Apps as a host type and writes the corresponding `services:` entry, e.g.:

```yaml
services:
web:
host: staticwebapp
project: src
dist: dist
```

Ideally `azd init --from-code` would also detect a static front end and scaffold the same entry.

**Why this matters**

Tooling built on azd currently has to write `azure.yaml` itself to make Static Web Apps deployable. That is exactly the kind of file ownership we'd rather leave to azd: the file is azd's contract, the schema is azd's, and third parties editing it risks drift as the schema evolves. Adding scaffolding support would let that tooling delegate the whole thing to azd.

This applies to Azure Functions as well -- `host: function` is deployable but not scaffoldable -- so a general fix covering the older host types may be preferable to a Static Web Apps-only one.

**Additional context**

There are many existing issues about *deploying* Static Web Apps with azd (#8583, #1847, #1759, ...), and azd continues to maintain that path actively. As far as I can tell there is no existing issue tracking the scaffolding gap, which is why I'm filing this one.