[Feature] Support azd up <service> with unified layer and service targeting

### Describe the request

Unify provisioning layers and deployable services as addressable project targets so customers can run:

```console
azd up
```

Today the command model is split:

- `azd provision []` selects infrastructure.
- `azd deploy ` selects application code.
- `azd up [flags]` always targets the whole project and accepts neither a service nor a layer.

This means a project cannot offer the natural one-command experience for a single service whose infrastructure is represented by a layer.

### Customer scenario

Consider a multi-service application with:

- shared infrastructure layers such as `resource-group` and `shared-resources`;
- service-aligned layers such as `frontend`, `api`, and `worker`;
- deployable services with the same logical names.

For an isolated frontend change, customers expect `azd up frontend` to provision the frontend layer and its infrastructure dependencies, then package and deploy only the frontend service. Today every project must build a custom wrapper or CI orchestrator around separate `azd provision frontend` and `azd deploy frontend` calls.

Customizing the static `workflows.up` sequence does not solve runtime target selection.

### Proposed behavior

Add `azd up ` and make the project model express the relationship between a service and its owning layer (for example, through the Layers v2 model rather than relying only on matching names).

For `azd up frontend`, azd should:

1. Resolve the selected service and its associated layer.
2. Provision that layer and its transitive infrastructure dependencies.
3. Package and deploy only the selected service, or its required service dependency closure.
4. Run project hooks once and the applicable layer/service hooks in deterministic order.
5. Use one environment-state writer for the complete operation.
6. Validate unknown or ambiguous targets before mutating Azure resources.

`azd up` without a target should remain backward compatible and continue to operate on the full project.

Infrastructure-only layers can remain addressable through `azd provision `. If `up` also accepts layer targets, the CLI should clearly distinguish infrastructure-only layers from layers containing deployable services.

### Expected customer value

- One consistent target model across `provision`, `deploy`, and `up`.
- A natural one-command path for partial application updates.
- Less project-specific orchestration and less duplicated dependency mapping.
- Correct hook and environment-state behavior compared with scripting multiple independent commands.

### Related work

- #9708 proposes deploying a selected service subset as one dependency graph and notes that Layers v2 can include services.
- #9854 tracks service addressing and ambiguity as services move into layers.

### Suggested acceptance criteria

- `azd up ` is documented and shown in `azd up --help`.
- The associated infrastructure dependency closure is provisioned.
- Only the selected service dependency closure is packaged and deployed.
- Project hooks run once; relevant layer and service hooks run once.
- Ambiguous service names produce an actionable error or support a qualified target syntax.
- Existing targetless `azd up` behavior is unchanged.