Release OCI retag can ship a different binary than the release assets

[keskad]

Problem

The release workflow retags the Android loco-server OCI image by copying the existing :main tag (scripts/retag-oci-loco-android.sh, .github/workflows/release.yml:105-106):

oras copy "${IMAGE}:main" "${IMAGE}:${RELEASE_TAG}"

publish-oci in ci.yml only runs on pushes to master/main and is skipped for version tag pushes. GitHub release assets come from the tag commit's CI build, but the GHCR :v* tag is copied from whatever :main currently points at — which may be a newer commit than the release tag if master advanced between the tag push and the release workflow running.

As a result, the OCI image consumed by bigfred-android-client (ghcr.io/dcc-bigfred/loco-server-android-arm64:v*) can be a different binary than the loco-server-android-arm64 artifact attached to the GitHub release for the same tag.

Impact

• Reproducibility: a phone APK pinned to :v1.2.3 may run a different loco-server than the one a developer reproduces from the v1.2.3 release assets.
• Debugging: logs from the phone may not match the source the user thinks they're running.
• Rollback: re-tagging :main after a bad push silently changes what a past :v* tag points to is not possible (oras copy is a snapshot), but a new release can still pick up an unrelated :main.

Suggested fix

Publish the OCI image from the release tag's own build artifacts instead of copying :main:

• Build the Android binary in the release workflow (or attach it as a release asset from the tag CI) and oras push it directly with the release tag, OR
• Have publish-oci also run on tag pushes (v*) and tag the image :v* + sha-<commit> from the tag commit, then drop the retag step from release.yml.

Either way, the :v* tag should be built from the same commit as the GitHub release assets.

Context

Flagged during review of PR #40 (Bugbot finding, severity: high).