Document and hint at the APK-filename/versionCode naming contract

publish.sh's overwrite guard (fdroid-repo-ci#6) is correct but implies a
contract nothing states: a colliding filename with no versionCode in it
means only the first publish into a prefix can ever succeed. Flutter's
constant app-<flavor>-release.apk hit this in weblib-viewer (#29), and the
failure only surfaces on the second publish with an error that reads like a
bucket-state problem.

Add the naming contract to the README, and append a hint to the refusal
message when the colliding object's basename has no digits at all -- a
pure text addition, never changing which publishes are refused.

Closes fdroid-repo-ci#13.

Co-authored-by: bit <bit@das-labor.org>

publish.sh

@@ -267,6 +267,18 @@ if [ "$run_files" = true ]; then
     fi
     if head_out=$("${aws_base[@]}" s3api head-object --bucket "$bucket" --key "$key" 2>&1); then
       echo "publish.sh: refusing to publish -- $key already exists in s3://$bucket (would overwrite an existing APK, fdroid-repo-ci#6)" >&2
+      # Hint only, never a control-flow change (fdroid-repo-ci#13): a
+      # colliding filename with no digits at all cannot be carrying a
+      # versionCode, which is the single most common way to trip this
+      # guard on every publish after the first -- Flutter's
+      # app-<flavor>-release.apk being the concrete case that motivated
+      # this. A filename that does contain digits still gets refused with
+      # just the message above, exactly as before; it may yet be a genuine
+      # collision (fdroid-repo-ci#6) and this heuristic cannot tell.
+      base=$(basename "$key")
+      if [[ $base != *[0-9]* ]]; then
+        echo "publish.sh: $base does not appear to carry a versionCode -- F-Droid's convention is <applicationId>_<versionCode>.apk; a constant filename plus this guard means only the first publish into a prefix can ever succeed" >&2
+      fi
       exit 1
     elif echo "$head_out" | grep -qi '404\|not found\|NoSuchKey'; then
       : # does not exist yet -- fine, this is the common case