[Security] Keep replication-slot status diagnostics confidential

[seonghobae]

Defect

Protected develop exposes ReplicationSlotProbe.safeMessage(...) through GET /api/cdc/status. Despite the method comment saying connection strings should not leak, it currently only truncates the most-specific exception message to 200 characters. A JDBC/driver exception containing a URL, username, credential fragment, host, filesystem path, or other operational detail therefore remains client-visible.

RCA

• Immediate cause: safeMessage equates truncation with sanitization.
• Root cause: fail-open operator diagnostics were designed without an explicit trust-boundary contract for the status API.
• Impact: connection/credential-shaped diagnostics can cross the public HTTP status boundary during database failures.

Bounded acceptance

Use strict test-first repair from the exact current protected develop head. Inject a DataAccessException whose most-specific message includes unmistakable connection/credential-shaped data and prove probeSlot keeps available=false and error=query_failed without returning the raw diagnostic. GREEN should expose only a stable, non-sensitive failure message/category while retaining useful structured status. Do not log the injected secret-shaped value. Run focused/full hosted validation and keep inherited scanner/coverage/literal-source governance blockers separate.

[seonghobae]

Duplicate of active Draft PR #170. Fresh exact-state revalidation on protected develop@942d164ceb7af497bb28a95f842db96429d1bdc4 confirms #170 is open, mergeable, based on that live protected tip at exact head 83d976f6c17c5ca101cd236f105c2859759e00db, and its two-file diff already contains the required credential-shaped DataAccessException regression plus the stable query_failed / Replication slot state unavailable production correction with raw driver diagnostics removed from ordinary logs. This issue adds no distinct defect or acceptance boundary; #170 remains unshipped until its independent gates pass.