fix(security): sanitize user-controlled fields before email rendering

[Emmanuelchukwunonso]

Summary

Investigated #194's premise before implementing: all 4 email templates already use html/template (not text/template), and none disable escaping via template.HTML(...). Verified empirically that html/template already contextually escapes malicious markup for every {{.Field}} substitution (e.g. <script>alert(1)</script> renders as <script>alert(1)</script>). Subject lines carry no user-controlled data, so header injection isn't reachable there either.

Added sanitizeEmailField() as defense-in-depth per the issue's literal acceptance criteria ("sanitize all user input before email rendering"): strips HTML/script tags and control characters (including CR/LF) from UserName, RecipientAccount, and Reason fields before they enter template data, so this property doesn't silently depend on every future template staying on html/template.

Also fixed (blocking, unrelated to this issue, pre-existing on main):

• handlers/auth.go: stray }) after ResetPassword's closing brace — a syntax error that blocks the whole module from building.
• go.mod: testcontainers-go v0.17.1 doesn't exist on the module proxy; pinned to v0.17.0.

Test plan

• go build ./services/...
• go test ./services/... -v — existing suite passes unchanged
• New email_sanitization_test.go: tag stripping, control-character stripping, whitespace trimming, and a pinning test for html/template's own auto-escaping

Closes #194

[parkerwinner]

fix conflict

[drips-wave]

@Emmanuelchukwunonso Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits