fix(email): RFC-correct In-Reply-To (§3.6.4) threading + RFC 2047 (§6.2) address display

[seonghobae]

Two small, independent, standards-grounded correctness fixes to Naruon email-header handling (one commit each).

1. RFC 5322 §3.6.4 — multi-id In-Reply-To threading (4dadff0)

assign_thread_id parsed In-Reply-To with normalize_message_id, which only strips </> off the whole string. RFC 5322 §3.6.4 defines in-reply-to = "In-Reply-To:" 1*msg-id — it may carry multiple message-ids. A legal "<parent@x> <cc-parent@x>" became the corrupted id "parent@x> <cc-parent@x", so the reply failed to join its parent thread and, when References was absent, became a mangled deterministic root (orphaned). Fixed to use the multi-id extract_reference_ids(...)[0] (first parent, per §3.6.4 and jwz message threading). Single-id/absent paths unchanged.

2. RFC 2047 §6.2 — encoded-word address display names (4cb34fe)

_sanitize_address_display_text decoded From/To/Reply-To display names via getaddresses (correct), then passed them through email.utils.formataddr, whose default charset='utf-8' re-encodes any non-ASCII display name back into an RFC 2047 encoded-word. So From: =?UTF-8?B?7ZmN6ri464+Z?= <hong@test.com> was stored/shown as =?utf-8?b?…?= <hong@test.com> instead of 홍길동 <hong@test.com>. RFC 2047 §6.2 requires encoded-words in a displayed header to be shown decoded; these fields are display+fingerprint surfaces never re-serialized into an outgoing message. Fixed with a local _format_address_display that mirrors formataddr's quoting/escaping (ASCII output byte-identical, verified) but never re-encodes. (Subject was already correct — it doesn't round-trip through formataddr.)

Type of change

• Bug fix (non-breaking change which fixes an issue)

Verification (from backend/, DISABLE_BACKGROUND_WORKERS=1 PYTHONWARNINGS=error)

• TDD for both: new tests fail on develop (assert the mangled/re-encoded output) and pass after the fix.
• pytest tests/test_threading_service.py → 8 passed; parser+threading+service → 39 passed.
• Broader email suites (import, dedupe, model reconciliation, emails API, threading pipeline) → 118 passed, 1 skipped; client/attachment suites → 103 passed. Zero Timeout/Fatal/Warn/Denied.
• ruff check on all changed files → clean.

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 8 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 90f88644-f808-44ca-9a71-632021b3d04e

📥 Commits

Reviewing files that changed from the base of the PR and between ab6442b and 05b94a9.

📒 Files selected for processing (4)

• backend/services/email_parser.py
• backend/services/threading_service.py
• backend/tests/test_email_parser.py
• backend/tests/test_threading_service.py

---

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

[seonghobae]

Closing after Loop drain: permanently blocked — branch was updated onto develop for mergeability, which cleared prior APPROVED robot evidence; re-review (CodeRabbit/OpenCode) and/or central gate jobs (metadata-only gate evaluation, coverage-evidence) remained pending/stuck without a re-runnable workflow handle. Not force-merging (merge-gate policy). Re-open a focused PR when robot capacity is available. Related product security fixes that reimplemented cleanly remain on branch goal/carddav-path-traversal-decode (#1206) for relaunch.

[github-actions]

PR governance metadata gate is not ready for 05b94a9ba1427d119d1917bae90d3f472b5918ee:

• Required check coverage-evidence is CANCELLED on the current head.
• Required check opencode-review is CANCELLED on the current head.
• Required check coverage-source-tree is CANCELLED on the current head.

[seonghobae]

Superseded by #1192 after current-head CodeGraph and branch comparison. #1192 preserves both behaviors from this PR (decoded RFC 2047 display names and RFC 5322 multi-ID In-Reply-To threading) and extends them with CFWS handling, folded Message-ID normalization, unknown-zone Date normalization, broader 100% parser/threading tests, and the standards-basis research pack. Closing the overlapping smaller PR to avoid competing edits to the same parser/threading files.