Add S3 guard to prevent publishing existing JARs

[Ben-El]

Closes #9387

This PR introduces a guard step in the Makefile to prevent accidental overwriting of existing spark client jars on treeverse-clients-us-east bucket.

Changes

• Added guard-s3-no-overwrite target:
  • Resolves bucket, project name, version, and jar name dynamically via sbt.
  • Builds the expected S3 object URL.
  • Uses curl to check whether the object already exists (HTTP 200) or is missing (HTTP 404).
  • If the object already exists, the build fails with a clear error message, instructing developers to bump the version or manually delete the old artifact.
• Updated publish-scala to depend on guard-s3-no-overwrite, ensuring the guard always runs before publishing.
• Removed the previous aws s3 cp --acl public-read ... step, as public accessibility is already ensured through bucket policies (and BPA - Block Public Access, is off, as well).

Why

Previously, publishing the same project version twice could silently overwrite existing jars in S3.
This posed two risks:

• Production instability - clients may fetch a “different” jar under the same version tag, leading to hard-to-debug behavior.
• Inconsistent artifacts - the same version string would no longer uniquely identify a binary.

With this guard, we enforce immutability of published artifacts unless a version is explicitly bumped.

Additional Safeguards

As part of hardening S3 usage, these options were also enabled:

• Bucket Versioning: ensures that every update creates a new object version instead of destroying history. This allows recovery of older artifacts even if a new one is mistakenly uploaded.

• S3 Object Lock (Governance mode): prevents object versions from being deleted or overwritten during a retention window (currently, default retention is disabled).
  This could add another layer of protection against accidental or malicious overwrites.

Together, versioning and object lock provide defense in depth:

• Versioning preserves history.
• Object Lock enforces immutability for a defined period, making sure published artifacts remain stable and reliable.

Testings

A new dedicated bucket benel-public-test was created for experimentation.

Configured it as public with the same policies as the production bucket (treeverse-clients-us-east).

Used as a sandbox to validate the updated publication process.

Verified that:

• Publishing a jar with a new version succeeds.
• Attempting to publish a jar with an already existing version fails due to the guard, as expected.
  see this for example.

• Confirmed that the publication process works without the redundant step:
  aws s3 cp --recursive --acl public-read $(CLIENT_JARS_BUCKET) $(CLIENT_JARS_BUCKET) --metadata-directive REPLACE.
  Bucket policies already guarantee public readability, making this step unnecessary.

• Verified public accessibility of uploaded jars using:
  curl -I https://<bucket>.s3.us-east-1.amazonaws.com/<path-to-jar>.
  which returned HTTP/1.1 200 OK, proving objects remain publicly accessible even without the ACL step.

• On the experimental bucket, versioning and object lock were enabled to test retention and overwrite-prevention behaviors.

• Verified that multiple versions are retained.

• Confirmed object lock prevents premature deletion/overwriting during the retention window.