Remote build fallback fails before starting a local Docker build

### Description

When `docker.remoteBuild: true` is enabled and an ACR build fails, azd says it is falling back to a local Docker build. In a normal command lifecycle, the fallback fails before Docker starts because the earlier build and package phases intentionally produced no local container artifact.

The final error replaces the useful ACR failure with:

```text
ERROR: failed publishing service 'app': failed retrieving package result details
```

This affects `azd publish` and commands that invoke the same publish phase, including `azd deploy` and `azd up`.

### Steps to reproduce

1. Start Docker or Podman locally.
2. Use a Container Apps project with an ACR and this service configuration:

```yaml
services:
app:
project: src/app
host: containerapp
language: js
docker:
remoteBuild: true
```

3. Provision the project.
4. Cause the remote Docker build to fail. For example, add this instruction to the Dockerfile:

```dockerfile
RUN definitely-not-a-real-command
```

5. Run `azd publish --no-prompt`.

The repository fixture at `cli/azd/test/functional/testdata/samples/containerremotebuildapp` can be used for this reproduction.

### Actual behaviour

The ACR build fails and azd prints its build log. azd then prints:

```text
Falling back to local Docker build.
```

The local Docker build does not start. `publishLocalImage` cannot find a target image in the package results and the command exits with `failed retrieving package result details`. The final error no longer contains the typed remote-build failure.

A live run on August 26, 2026 reproduced this sequence. A valid baseline remote build completed first. After the Dockerfile was changed, ACR reported the run as failed, the fallback message appeared, and the command ended with the package-result error above.

### Expected behaviour

The fallback path should work with the state produced by the normal `Build`, `Package`, and `Publish` lifecycle. If the overall publish still fails, the final error should retain useful context from the remote build and the fallback attempt.

### Context

Automatic fallback was introduced in #7041. The existing unit test supplies a local container package artifact directly, but normal `remoteBuild: true` processing skips local build and package work. As a result, the test does not cover the state passed to `Publish` by a real command.

This also masks the status-specific remote-build diagnostics added by #9737 when the local fallback is attempted and fails.