fix: retry BTP V4 publication after a missing-inbound error

[marianfoo]

A BTP OData V4 UI publish can return Inbound service <binding>_0001_G4BA does not exist even when repeating the same request later succeeds. ARC-1 adds one bounded recovery attempt for that exact English error on service version 0001.

Recovery reads active state, waits ten seconds on this error path, checks again, revalidates the real package and write ceiling, and retries once. Already-published state returns confirmed success without another POST. Unknown state, persistent errors and cancellation stop recovery. Success requires an explicit published readback; the original failure and recovery outcome remain visible. A 150-second deadline and 20-send HTTP budget start after the initial error, including existing protocol fallbacks. Dependencies are never recreated or reactivated.

Normal publish/unpublish behavior and tool schemas remain unchanged. This is a scoped recovery measure, not a confirmed SAP backend root-cause fix.

Validation:

• 6,836 unit tests passed in 222 files; all 50 new focused tests passed again on September 17.
• Actual loopback HTTP tests cover concurrent identities, MIME fallback within the same send budget, denied metadata reads, package changes and cancellation.
• Build, typecheck, lint, action-policy validation, file-size and tool-schema gates passed. Every GitHub check on tested product revision b156f805 passed, including integration and E2E.
• Changed build verified live on BTP, SAP_BASIS/SAP_CLOUD 920 SP04: nine ordinary first publications succeeded with one physical POST and explicit active readback. Variants included immediate publish, a ten-second pre-wait, identical SRVD update, and a fresh HTTP client with the same identity.
• Deliberately removing an owned generated SCO2 exercised the exact error and new recovery path: two physical publish POSTs, both returned the error, final state explicitly unpublished, no third POST. This validates bounded failure behavior, not natural transient recovery.
• A separate controlled create-response-loss spike demonstrated unsafe generic POST replay after synthetic 503, including a real SAP already-exists response. A local no-replay prototype avoided that duplicate. No transport-policy changes are included in this PR, and this does not prove the customer's 409 or proxy cause.

The plan, updated verification, and September 17 investigation distinguish natural runs, deliberately induced failures, the separate create issue and remaining evidence needs.

Draft: Personal authentication and changed-build live verification are now complete. Natural transient failure followed by successful live recovery remains unobserved on this tenant; the separate Usage of <SRVD> not permitted activation failure is also unreproduced. Keep this distinction when evaluating customer validation and merge readiness.