fix: accounts created via CLI can't authenticate with real kosync clients

[inaltoasinistra]

Fixes #130

Summary

• kosync clients (KOReader, CrossPoint, etc.) always MD5-hash the password
  client-side before sending it, both at registration (POST /users/create)
  and at login (x-auth-key header). The server just Argon2-hashes whatever
  string it receives, so it never needs to know this is happening — as long
  as both the stored value and the login value went through the same
  transform.
• korrosync user create / korrosync user reset-password took the admin's
  typed password literally and Argon2-hashed it as-is, skipping the MD5 step
  a real client always performs. That meant CLI-created accounts stored
  Argon2(password) while every real client would send MD5(password) as
  x-auth-key — so login always failed with 401 Unauthorized, even with
  the correct password.
• Added korrosync::model::md5_hex, and the CLI now runs the typed password
  through it before hashing, so CLI-created/reset accounts store the same
  credential a client-driven POST /users/create call would produce for the
  same password.

Test plan

• src/model/user.rs: unit tests for md5_hex (RFC 1321 known-answer
  vector, determinism, distinctness)
• tests/user_cli_password_test.rs (new): spawns the real korrosync
  binary to run user create / user reset-password, then verifies
  login succeeds with the MD5-hashed key a real client sends and fails
  with the raw plaintext password; also verifies a CLI-created account
  and an API-registered account authenticate identically given the same
  real password
• cargo test, cargo fmt --check, cargo clippy --all-targets -- -D warnings
• Manually verified against a running server with curl (MD5-hashed
  x-auth-key → 200 OK, raw plaintext x-auth-key → 401)