🔐 [Security Bug] Password Reset & Verification Codes Stored in Plaintext

### Summary
Password reset codes and account verification codes are currently stored **in plaintext** in the database.
If the database is ever compromised, an attacker could immediately verify accounts or reset passwords without user interaction.

---

### Affected Area
- **File:** `backend/controllers/auth.go`
- **Feature:** Account verification & password reset flows

---

### Description
The application generates verification and password reset codes and stores them directly in the database without hashing or encryption.

This creates a security risk because:
- Codes function as authentication secrets
- Plaintext storage allows direct reuse by an attacker
- No additional protection (hashing / expiry enforcement) exists

---

### Expected Behavior
- Verification and reset codes should be treated as secrets
- Codes should be **hashed before storage**
- Incoming codes should be verified using secure hash comparison
- Raw codes should never be persisted

---

### Actual Behavior
- Codes are stored in plaintext
- Any database read access exposes valid authentication tokens

---

### Security Impact
- Database compromise leads to **immediate account takeover**
- Violates standard authentication security practices
- Increases blast radius of any data breach

---

### Steps to Reproduce
1. Trigger account verification or password reset
2. Inspect the user record in the database
3. Observe the verification/reset code stored in plaintext

---

### Recommended Fix
- Hash verification and reset codes before storing them
(e.g., SHA-256 or HMAC with a server secret)
- Compare hashes when validating codes
- Optionally add:
- Expiration timestamps
- Single-use enforcement

Start in backend/controllers/auth.go and trace the account verification and password reset flows from code generation through database storage and validation. Done means raw codes are not persisted, incoming codes are checked against stored hashes, and both flows still work securely with the existing expiry behavior.

Written by the indexing model from the issue text.