fix(etl): declare UTF-8 for successful text responses

[seonghobae]

What changed

The successful synchronous ETL response now declares its actual encoding:

Content-Type: text/plain;charset=UTF-8

The response body and newline-delimited plain-text representation are unchanged. Failure responses, idempotency headers, request handling, authentication, catalog behavior, and persistence are unchanged.

Why this change

Issue #235: EtlController.processData(...) returned a Java String as MediaType.TEXT_PLAIN without a charset. The ETL validation contract permits non-ASCII record identifiers, so a successful body such as Processed: 레코드_α was not self-describing at the HTTP boundary. Clients should not need to guess the encoding.

The production change is limited to EtlController.java: new MediaType(MediaType.TEXT_PLAIN, StandardCharsets.UTF_8). The focused regression test drives the real standalone MVC response boundary with a non-ASCII result and asserts the exact header plus body preservation.

Test-first evidence (local, Temurin 25)

RED on exact protected origin/develop@e550688c before the production change: EtlControllerTest 1 failure / 24 tests, at declaresUtf8CharsetForNonAsciiSuccessBody because the successful response had no charset.

GREEN after ca0f326b: focused EtlControllerTest 24/24; full etl-service module 231 tests, 0 failures, 0 errors with the JaCoCo gate.

Acceptance mapping (issue #235)

1. Test-first real MVC RED for a non-ASCII success body and missing charset — covered.
2. Exact text/plain;charset=UTF-8 response — covered by content type and raw header assertions.
3. Non-ASCII response text preserved — covered by Processed: 레코드_α body assertion.
4. Existing ASCII, keyed/idempotent, failure, authentication, and catalog tests remain green — full etl-service suite passed.
5. No OpenAPI file exists in this repository to reconcile in this slice; docs continue to describe the same 200 text/plain representation.

Non-goals

• Does not replace the newline-delimited plain-text representation.
• Does not change OpenAPI paths or status codes.
• Does not normalize or transliterate Unicode identifiers.
• Does not alter request JSON encoding or database persistence.
• Does not fold direct ETL authentication issue [Product/Security Gap] Replace direct ETL HTTP Basic trust boundary #161 into this response-encoding repair.

Closes #235

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[seonghobae]

This PR duplicates the existing active owner PR #236 for issue #235 (same EtlController response boundary). My local branch reached RED 1/24, GREEN 24/24, full etl-service 231/0/0, but #236 is the canonical owner and should carry review/integration. Handing off to #236 and closing this duplicate.

[seonghobae]

Superseded by canonical active owner PR #236; local evidence was handed off in the preceding comment.