OSIS-166: preserve Vault server faults (5xx) instead of masking them as 400

[anurag4DSB]

Intent: why does this change exist?

The six create/update endpoints downgraded every Vault failure to 400, so a genuine Vault server error reached the error boundary as a client 400 and was logged at INFO with no stack trace. That hid intermittent Vault server faults from the logs (full outages are still caught by VaultHealthIndicator). Found in review of #159.

System impact: what's affected, including downstream?

ScalityOsisServiceImpl: createTenant, createUser, createS3Credential, updateCredentialStatus, updateUser, updateTenant. OSE now receives a 5xx (instead of 400) from these endpoints when Vault itself returns a server error; a transient Vault failure reads as retryable rather than as a bad request. Stacked on #159.

Preserved behavior: what explicitly stays the same?

Client-side Vault rejections (4xx) still map to 400 and log at INFO with no trace. updateTenant keeps its E_BAD_REQUEST errorCode on the 400 path. Non-Vault exceptions in these paths still map to 400 as before. The error boundary, response body shape, and logging seam are unchanged.

Intended change: what's different after this PR?

A genuine Vault server fault (5xx) propagates with its 5xx status, so the single error boundary logs it once at ERROR with the stack trace. A small toResponseException helper centralizes the rule; updateTenant keeps it inline to retain its errorCode. The boundary stays the only place that logs, so this keeps the "log once" invariant rather than re-adding a service-layer ERROR log.

Verification: how do we know this worked, or how would we know if it didn't?

./gradlew build green (incl. JaCoCo 75%, SpotBugs, PMD). New tests assert createTenant and updateTenant surface a Vault 500 as 500, not 400; the existing 400-mapping and consistency tests still pass.

---

🤖 Generated with Claude Code · Jira: OSIS-166

[claude]

LGTM — logic is correct and well-scoped. The toResponseException helper and the inline updateTenant variant both preserve 5xx faithfully; the error boundary already handles both paths (5xx → ERROR with trace, 4xx → INFO). No catch blocks were missed. Tests cover both code paths (helper via createTenant, inline via updateTenant).

Review by Claude Code

[anurag4DSB]

Superseded by #169, which re-creates the 5xx passthrough minimally on top of main (works via Spring's default ResponseStatusException handling, no error boundary needed). Closing this one.