Reject passwords containing user's personal info

[iamtanuj18]

Fixes #902

Currently checkPasswordStrength only checks the password itself, so a
password like Firstnamelastname2026! passes all requirements even
though it's tied to who the user is. This PR extends the check to
reject passwords containing the user's name, email local part, or DOB
year.

Approach

• checkPasswordStrength gets an optional context param carrying
  firstName, middleName, lastName, email, and dob (each optional).
• Each context field is tokenised: split on whitespace, lowercased,
  tokens of at least 4 characters retained. Email uses the part before
  @ (the domain isn't flagged as PII). DOB uses the 4-digit year.
• If any resulting token appears as a substring of the password
  (case-insensitive), the check fails with a PersonalInfo field
  naming the specific matched token.

Where it's wired

Server-side (authoritative):

• AuthController.registerParticipant - name, email, dob from body
• AuthController.registerUser - name and email from body
• AuthController.registerInitialUser - only email (setup form doesn't
  collect names)
• UsersController.resetPassword - name and email from the token's
  user relation, plus a ParticipantProfile lookup for dob
  (participants only)

Client-side (submit-time UX):

• user-client/Register.tsx - pulls all four via RHF getValues()
• admin-client/setup/index.tsx - pulls email

The two reset-password forms don't have PII fields on them, so
client-side is a no-op there and the server handles rejection.

Tests

• PasswordStrength.test.ts - unit tests (backwards compat, each PII
  field, case-insensitivity, the 4-character filter, multi-word names,
  empty context, error message content, multiple simultaneous failures)
• ResetPassword.test.ts - integration case for a PII password rejected
  end-to-end through the reset flow
• Cypress cases for participant register, admin setup, and admin reset
• seed.ts - PASSWORD_RESET_USER placeholder firstName/lastName
  changed to values that don't collide with common test passwords

Scope

• The env-driven bootstrap admin path (createAdmin.ts) isn't touched
  here; strength enforcement for that path is handled by Enforce password strength check in createAdmin.ts #908.
• The setup form still only collects email + password (pre-existing),
  so the setup admin gets an email-only check. Adding names to the
  setup form would be a separate ticket.