fix(publishing): bound push-publish connect attempts, isolate per-bundle failures, report due queued bundles as BUNDLE_REQUESTED (#37449)

[hassandotcms]

Implementation (PR 2 of 2) for #37449. Spec approved in #37450.

What changed

• Push-publish HTTP clients (bundle upload and status poll) now carry a connect timeout, PUSH_PUBLISH_CONNECT_TIMEOUT_MS, default 10 s, 0 = unbounded. Before, an endpoint that never answered blocked the publisher job for the operating system's TCP timeout, about two minutes per attempt, and every bundle queued behind it waited.
• PublisherQueueJob finalizes a bundle that fails unexpectedly and continues with the next one, instead of ending the run.
• GET /api/v1/publishing and GET /api/v1/publishing/{id} report a queued bundle whose publish date is already due as BUNDLE_REQUESTED with createDate equal to its publish date. SCHEDULED now means future-dated only. The Publishing Queue portlet already renders both.

Release note

status=SCHEDULED on GET /api/v1/publishing now returns only future-dated queued bundles. Queued bundles whose publish date is already due are returned under BUNDLE_REQUESTED. Scripts that used SCHEDULED to find all waiting bundles should query both.

Tests

• PublisherQueueJobTest: client factory applies the configured timeout and leaves RestClientBuilder untouched; an unexpected error in one bundle finalizes it and the next bundle is still processed.
• PublishingResourceIntegrationTest: due queued bundle reported as BUNDLE_REQUESTED in list and detail; SCHEDULED and BUNDLE_REQUESTED filters split due and future.
• Regression: BundleManagementResourceIntegrationTest, PublisherAPIImplTest, AuditPublishingResourceTest green.

No frontend, legacy DWR/JSP, RestClientBuilder, schema or receiver-side change. Rollback-safe.

This PR fixes: #37449