Add opt-out for default upload connection-fault retries (single-file duplicate-version risk, esp. Object Lock) #368

Problem

PR #344 made upload POST connection-fault NetworkErrors retry by default with a fresh upload URL. For single-file uploads, if the first POST reached B2 before the connection dropped, the retry creates a duplicate file version — most damaging in versioned / Object Lock buckets, where the duplicate cannot be deleted until its retention expires. (Multipart is safe: re-uploading the same part number replaces it.)

Today the only way to disable this is retry.maxRetries: 0, which disables all retries (503, BadAuthToken, bad-upload-URL, backoff). Object Lock users who still want normal retries have no way to turn off just the duplicate-creating one.

This behavior was not explicitly reviewed for the Object Lock duplicate case before #344 merged.

Ask / Acceptance criteria

• A narrow, per-client and per-call option (e.g. retryUploadConnectionFaults, default true) that disables only the upload POST connection-fault retry when set to false.
• All other retryable classes (503, BadAuthToken, isUploadUrlInvalidationError, B2Error.retryable, backoff, SSRF handling) remain unchanged when the option is off.
• The current default is preserved (non-breaking); whether the default should flip to opt-in is a separate product decision and out of scope here.
• Docs (README, MIGRATION, CHANGELOG) clearly state the duplicate-version caveat for single-file uploads and how to opt out.
• Tests that fail without the change (default still retries; option-off does not retry a connection fault but still retries 503 / bad-upload-URL).

Scope / out of scope

• In scope: the opt-out control + docs + tests.
• Out of scope: flipping the default to opt-in (needs team sign-off); any multipart change (already safe).

Links

• Behavior introduced by: Fix: Retry upload POST connection failures by default #344
• Related integrity fix: fix(upload): preserve SHA-1 integrity during large-file resume #365