upload-blobs: do not attempt unless S3-related vars are set

[alxndrsn]

Closes #1476

What has been done to verify that this works as intended?

• tested script locally with S3-related vars set:

$ S3_SERVER=x ./files/service/scripts/upload-blobs.sh; echo $?
./files/service/scripts/upload-blobs.sh: line 13: cd: /usr/odk: No such file or directory
1
$ S3_BUCKET_NAME=x ./files/service/scripts/upload-blobs.sh; echo $?
./files/service/scripts/upload-blobs.sh: line 13: cd: /usr/odk: No such file or directory
1
$ S3_SERVER=y S3_BUCKET_NAME=x ./files/service/scripts/upload-blobs.sh; echo $?
./files/service/scripts/upload-blobs.sh: line 13: cd: /usr/odk: No such file or directory
1

• tested script locally without S3-related vars set

$ ./files/service/scripts/upload-blobs.sh; echo $?
0

Why is this the best possible solution? Were any other approaches considered?

Recommended in #1476 (comment).

How does this change impact users? Describe intentional behavior changes from code updates. What are the regression risks?

Should clean up logs a little.

Is this change user-facing or otherwise noteworthy to users? If so, please add an entry for it in CHANGELOG.md.

• done

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No.

[matthew-white]

Suggested change

	## next
	## 2026.4.0

Thank you for adding to the changelog! I think we can start building the changelog for .4 now. It won't be visible on the master branch or linked to from release notes until the release is out.

[alxndrsn]

Changing as advised, but is it misleading labelling this as changed in a version which isn't released? Would next in case the next release is a patch?

[matthew-white]

I don't think we'll release a patch off next; we'll use a different branch instead. We've had one patch so far and will probably have another one soon. However, I don't think we need to include this change in the patch. Unless you think we should (that would be great too), in that case we could edit the changelog manually.

[matthew-white]

is it misleading labelling this as changed in a version which isn't released?

I think we do something similar for the Backend/API changelog. E.g., docs/api.yaml in the master branch of central-backend has an entry for .4 even though we haven't released that version yet. In central-backend, we build up the changelog as we go.