Account for missing ACR images for build that only affects a portion of a shared tag

There can be a scenario that will cause the [`publishManifest` command](https://github.com/dotnet/docker-tools/blob/3a078d892227e6446a5bcaf13536b8e37934685d/src/Microsoft.DotNet.ImageBuilder/src/Commands/PublishManifestCommand.cs#L19) to fail.

Conditions:
* A .NET version has become EOL and its associated images have been marked with EOL annotations.
* Dockerfiles for that version have not yet been deleted from the repo.
* Cleanup pipeline has deleted those EOL images from the ACR.
* A base image of one of those Dockerfiles (e.g. Debian Bullseye) is updated, but only for a subset of the total set of architectures we have Dockerfiles for (e.g. amd64).
* AutoBuilder runs a build to rebuild the affected Dockerfiles.

With these conditions, the `publishManifest` command will fail in the publish stage. This occurs because, when creating the manifest list for the shared tag (e.g. `6.0-bullseye`), it needs to query the ACR to get the digests of all the images associated with that that. Since the pipeline didn't rebuild _all_ of the architectures, there is no image for the architecture that was not updated in the ACR. So the query to get that image's digest fails.

The command we currently use to create the manifest list is exemplified by the following:

```
docker manifest create --amend \
dotnetdocker.azurecr.io/public/dotnet/runtime-deps:6.0-alpine \
dotnetdocker.azurecr.io/public/dotnet/runtime-deps:6.0.36-alpine3.20-amd64 \
dotnetdocker.azurecr.io/public/dotnet/runtime-deps:6.0.36-alpine3.20-arm32v7 \
dotnetdocker.azurecr.io/public/dotnet/runtime-deps:6.0.36-alpine3.20-arm64v8
```

We could investigate whether using `docker buildx imagetools create --append` could be used here instead.

Another lower-cost solution would be to extend the time period we use before deleting EOL images from the ACR. If this was extended past 1 month to allow for the 1 month grace period after the .NET version EOL date, then we could avoid this.