Layers v2: define behavior for projects with no infrastructure entries

## Context

A layers v2 project may contain services without declaring any infrastructure:

```yaml
layers:
- name: application
services:
api:
host: containerapp
image: example/api
```

Layers v2 infrastructure is currently flattened into `provisioning.Options.Layers`. When the flattened list is empty, it is indistinguishable from the legacy `infra.layers: []` representation.

Legacy behavior treats an empty `Options.Layers` collection as the single root infrastructure entry. As a result, a layers v2 project with no infrastructure entries may attempt to use the default Bicep provider rather than treating provisioning as a no-op.

It is not yet clear whether a layers v2 project without infrastructure is a supported customer scenario. We should make that decision explicitly and represent it without changing legacy `infra.layers: []` behavior.

## Expected outcome

- Decide whether layers v2 projects may contain zero infrastructure entries.
- If supported, ensure `azd provision`, `azd up`, `azd down`, pipeline configuration, and environment refresh handle them consistently.
- Preserve legacy behavior for `infra.layers: []`.
- Add tests covering the chosen behavior.

Part of #9767

Start with the layers v2 flattening and legacy infra.layers handling, then trace azd provision, azd up, azd down, pipeline configuration, and environment refresh. Decide whether zero infrastructure is supported, represent that distinction without changing legacy behavior, and add tests covering the chosen behavior consistently.

Written by the indexing model from the issue text.