CI: GHCR denies tag creation for cached Debian artifacts

### Summary

CI intermittently fails while publishing cached Debian packages to GHCR:

- [Failing Debian build job](https://github.com/canonical/authd/actions/runs/32146155706/job/95740328617?pr=1802)

The failure is:

```text
denied: denied
```

It occurs during:

```text
oras tag ghcr.io/canonical/authd/authd-deb-devel:72f6205... a08927d...
```

The preceding GHCR login, cache pull, and `oras push` succeed. The `noble` and `resolute` jobs in the same run also succeed, as do other GHCR uploads and downloads. This is therefore not a general `packages: write` permission failure.

### Likely cause

On an OCI cache hit, `debian-build.yaml` still re-pushes the cached artifact and creates a commit-SHA tag. E2E and Debian Packaging workflows share the same GHCR repositories and cache tags, so concurrent runs repeatedly mutate the same tags. This creates unnecessary package versions and can cause GHCR tag operations to be rejected.

### Proposed fix

- Use the build-files hash as the canonical Debian artifact tag.
- Do not re-upload cached Debian or broker artifacts.
- Avoid creating mutable commit-SHA aliases.
- Skip VM-image uploads when the fixed GHCR tag already exists.

The exact GHCR backend reason is not exposed beyond the generic `denied: denied` response.

Start with debian-build.yaml and the failing Debian build job, then compare the E2E and Debian Packaging workflows that share GHCR repositories and cache tags. Trace the cache-hit path and verify that canonical build-files tags avoid re-uploads, mutable commit-SHA aliases, and redundant VM-image uploads when the fixed tag exists.

Written by the indexing model from the issue text.