discussion: align CommitNumRetriesDefault with Java/PyIceberg (0 → 4)?

Parent: #830

Open question, not a blocker. iceberg-go's `CommitNumRetriesDefault` was set to `0` in PR #912 because the retry loop without refresh-and-replay was harmful (re-issued the same stale conflict). PR #945 added refresh-and-replay, so the original reason for the `0` default is gone — but the constant has not been flipped.

Java and PyIceberg both default to `4` retries. A user porting from either of those clients sees fail-fast on the first conflict today and has to dig into properties to figure out why. The fix is a one-line constant change plus a sweep of tests that assume the no-retry path.

Reasons to flip:
- Java parity / out-of-box experience.
- The retry mechanism is fully wired and exercised in CI.
- Existing users who *want* fail-fast can set `commit.retry.num-retries=0` explicitly.

Reasons to hold off:
- Existing users (since #912 in April) have been running with default `0`. Flipping silently changes their commit-latency profile under contention — a 4-attempt exponential-backoff loop can add seconds before a terminal error surfaces.
- Some retry tests calibrated for `0` would need adjustment.

Filing as a question, not a feature, because the answer is a defaults-tuning judgment call rather than a missing capability. Looking for input from maintainers on whether the parity argument outweighs the silent-behavior-change concern, and ideally a release note if we do flip.

Start by reviewing PR #945 and the retry tests that assume CommitNumRetriesDefault is 0. The issue is done only after maintainers decide whether to change the default; if it changes, update the constant, adjust affected tests, and add the requested release note.

Written by the indexing model from the issue text.