Fix/client side password hashing

[NeonCharlie-24]

Description

Moves password hashing to the frontend so the backend never receives plaintext passwords. The frontend now SHA-256 hashes passwords using the Web Crypto API before sending them to the backend, where they are then bcrypt-hashed for storage. API field renamed from password to password_hash to make the contract explicit.

Issues

Closes #27

Other Notes

• Breaking change: This is not backwards-compatible. All existing users will need to re-register, as their stored bcrypt hashes were derived from plaintext passwords rather than the newly generated SHA-256 hashes.

• Manually verified via browser DevTools that /auth/signup and /auth/login request payloads contain SHA-256 hex strings instead of a plaintext strings. Confirmed signup and login both succeed end-to-end.

• Before:

• After:

Made with Cursor.

[NeonDaniel]

Hmm.. Looking at this being a breaking change and thinking about potential solutions to backwards-compat.

I think one option would be to fall back to parsing plaintext password as a fallback auth flow (i.e. Client sends hash, gets auth error, sends plaintext, server updates database using new hash method).

Another option would be not change password handling here and instead move to implement and prefer oauth to replace native authentication.

I'll put some more thought into this, but open to ideas/suggestions.