feat(security): add honeypot field to contact form

- Added a hidden `website` input field to the contact form as a honeypot.
- Implemented silent rejection logic: if the honeypot is filled, the form simulates success but does not send the email.
- Added a `.honeypot` CSS class to visually hide the field while keeping it accessible to bots.
- Updated `src/pages/Contact.tsx` to handle the new field and logic.
- Updated `src/pages/__tests__/Contact.test.tsx` to verify the honeypot logic and fixed existing tests that were failing due to blocked domain usage (`example.com`).
- Recorded security learnings in `.jules/sentinel.md`.

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

.jules/sentinel.md

@@ -27,3 +27,8 @@
 **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.
+
+## 2026-02-14 - Blocked Domains in Test Data
+**Vulnerability:** Tests failing unexpectedly on valid inputs can lead to disabling security features or ignoring real bugs.
+**Learning:** The application blocks specific domains (like `example.com`) in its validation logic. Using these domains in test data (e.g. `john@example.com`) causes tests to fail with "Invalid email", confusing debugging efforts.
+**Prevention:** Always use safe, non-blocked domains (e.g. `valid-email.com` or a custom test domain) in test fixtures, and check the security configuration (`BLOCKED_DOMAINS`) when validation tests fail unexpectedly.