Greptile Summary

This PR fixes a PII leak in media fetch error paths where raw error messages containing group IDs, phone numbers, usernames, and file paths were being forwarded to public-facing channels (Discord, Telegram, etc.). The fix introduces a SAFE_MEDIA_FETCH_ERROR_MESSAGE constant and an isMediaFetchError() helper in src/media/fetch.ts, and applies sanitization at three defensive boundary points.

Key changes:

• src/media/fetch.ts: New SAFE_MEDIA_FETCH_ERROR_MESSAGE constant ("⚠️ Media failed: unable to fetch attachment.") and isMediaFetchError() that traverses the Error.cause chain to detect MediaFetchError at any nesting depth
• src/infra/outbound/message-action-params.ts: Catches MediaFetchError from loadWebMedia, logs the original message via logVerbose, then re-throws as a wrapped Error with the safe message
• src/infra/outbound/message-action-runner.ts: Sanitizes the error in handleBroadcastAction results using isMediaFetchError
• src/infra/outbound/deliver.ts: Sanitizes the error in emitMessageSent using isMediaFetchError; non-Error thrown values now resolve to "unknown error" instead of String(err) (a deliberate defensive change to avoid leaking stringified non-Error objects)
• Good unit test coverage in both fetch.test.ts (12 tests covering isMediaFetchError and the safe message) and message-action-runner.media.test.ts (end-to-end PII non-exposure assertion)

Minor note: The safe message in code ("⚠️ Media failed: unable to fetch attachment.") differs slightly from the example in the PR description ("⚠️ Media fetch failed. The attachment could not be retrieved.") — the code string is the authoritative one and is fine.

Confidence Score: 5/5

• This PR is safe to merge — it addresses a real PII leak with a well-structured, defensively layered fix and adequate test coverage.
• The security fix is correct: three sanitization boundaries are applied, isMediaFetchError() correctly traverses cause chains, the safe message contains no PII patterns, and the original error is intentionally preserved in the cause chain for internal logging only. The one P2 observation (.toContain vs .toBe in the test) is non-blocking. No critical logic errors or data-loss risks are present.
• No files require special attention

This is a comment left during a code review.
Path: src/infra/outbound/message-action-runner.media.test.ts
Line: 532

Comment:
**Strengthen assertion to `toBe` for exact match**

The test uses `.toContain(SAFE_MEDIA_FETCH_ERROR_MESSAGE)` to verify the sanitized error message. Since `SAFE_MEDIA_FETCH_ERROR_MESSAGE` is the entire expected string, a `.toBe` assertion is more precise and will catch any regression where PII is prepended or appended to the safe message (which `.toContain` would silently miss).

```suggestion
      expect(errorText).toBe(SAFE_MEDIA_FETCH_ERROR_MESSAGE);
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(media): remove fragile string-match ..." | Re-trigger Greptile}