[Security] Do not expose CDC shutdown exception details to API clients

[seonghobae]

Defect

Protected develop currently returns IOException.getMessage() directly from POST /api/cdc/stop when CDC shutdown fails. Exception messages at this boundary can contain filesystem paths, broker/host details, connector identifiers, or other operational internals and therefore should not be reflected to an unauthenticated/untrusted API client.

RCA

• Immediate cause: CdcController.stopCdc() concatenates the raw exception message into the HTTP 500 body.
• Root cause: this older endpoint predates the repository's newer bounded/problem-detail error-handling conventions and has no regression asserting diagnostic confidentiality.
• Impact: internal operational details can cross the public HTTP trust boundary during shutdown failures.

Bounded acceptance

Use strict test-first repair from the exact current protected develop head. RED must inject an IOException containing unmistakably sensitive diagnostic text and prove the HTTP response does not contain that text. GREEN should return a stable generic 500 message while preserving the status and stop invocation. Do not log or otherwise re-expose the injected secret-shaped diagnostic. Run the focused controller test and the full hosted reactor, and keep inherited/shared scanner or coverage governance blockers separate from this source defect.

[seonghobae]

Duplicate of active Draft PR #172. Fresh exact-state revalidation on protected develop@942d164ceb7af497bb28a95f842db96429d1bdc4 confirms #172 is open, mergeable, based on that live protected tip at exact head a443d23ec5f43342c2ec50790174da069cc7ba35, and its two-file diff already contains the required test-first shutdown confidentiality regression plus the stable CDC process could not be stopped production correction. This issue adds no distinct defect or acceptance boundary; #172 remains unshipped until its independent gates pass.