Push Publish: same bundle can be re-triggered while already publishing (non-idempotent under concurrent uploads)

Problem Statement

Push Publish receiver flow has a non-idempotent behavior for the same bundle under concurrent/repeated uploads.

BundlePublisherResource (and other upload paths) tries to avoid re-triggering when status is PUBLISHING_BUNDLE, but the guard is ineffective:

caller checks if (!status.equals(PUBLISHING_BUNDLE))
updateAuditTable(...) always builds and returns a new status set to RECEIVED_BUNDLE
So the condition is effectively always true and the same bundle can be queued again even while it is already in progress.
Operational impact under load:

duplicated processing of same bundle
status regressions/overwrites in audit history
unpredictable publish lifecycle and harder troubleshooting
Backend issue only (no browser/OS dependency).

Steps to Reproduce

Use a receiver endpoint and upload the same bundle.tar.gz twice in very short interval (or concurrent requests).
Ensure first processing has already started (PUBLISHING_BUNDLE) when second upload arrives.
Observe upload path logic:
updateAuditTable(...) returns RECEIVED_BUNDLE
guard if (!status.equals(PUBLISHING_BUNDLE)) passes
another PushPublisherJob trigger is scheduled for same bundle
Check audit/status history for non-deterministic state progression and repeated processing attempts.

Acceptance Criteria

Re-upload of the same bundle while it is already PUBLISHING_BUNDLE does not schedule a second processing job.
The in-progress guard is based on authoritative current persisted status (not a freshly constructed status object).
Uploading same bundle concurrently is idempotent: one effective processing execution per bundle-at-a-time.
Audit status does not regress from in-progress/final states back to RECEIVED_BUNDLE due duplicate upload path.
Integration test covers concurrent duplicate uploads of same bundle and validates deterministic lifecycle.

dotCMS Version

26.03+

Severity

High - Major functionality broken

Links

NA

Start with BundlePublisherResource and the other upload paths that call updateAuditTable(...), then trace how the receiver endpoint schedules PushPublisherJob. Reproduce duplicate uploads while the status is PUBLISHING_BUNDLE and inspect the audit/status history. Done means one effective processing execution per bundle at a time, no status regression, and an integration test covering concurrent duplicate uploads.