feat(security): add blocked domains and strict TLD validation

- Adds `BLOCKED_DOMAINS` list to reject disposable/invalid email domains.
- Enforces TLD length >= 2 chars in `isValidEmail`.
- Updates tests to cover new validation rules.

Co-authored-by: ragusa-it <196988693+ragusa-it@users.noreply.github.com>

.jules/sentinel.md

@@ -22,3 +22,8 @@
 **Vulnerability:** Standard email validation often allows characters like quotes (`"`) or backticks (`` ` ``) which can be vectors for XSS in HTML attribute contexts.
 **Learning:** While RFCs allow quoted local parts (e.g., `"user"@example.com`), these are rare in practice and pose significant security risks in web applications. It is often safer to explicitly reject them. However, apostrophes (`'`) are common in names (O'Connor) and should be allowed, relying on sanitization (Defense in Depth) rather than validation to handle them safely.
 **Prevention:** Use a hybrid approach: Strict validation (reject quotes/backticks) for high-risk characters, coupled with output sanitization (`sanitizeInput`) for characters that must be allowed but are still risky (apostrophes).
+
+## 2026-02-14 - Blocking Disposable Domains
+**Vulnerability:** Allowing users to register or submit forms with disposable email addresses (e.g., mailinator.com) can lead to spam, abuse, and polluted data.
+**Learning:** While true email verification requires a backend or API, a simple client-side blocklist of common disposable domains is a highly effective, low-cost first line of defense.
+**Prevention:** Maintain a list of known disposable domains (e.g., `BLOCKED_DOMAINS`) and check the domain part of the email address during validation.