fix: describe password maximum length in bytes

[KYHyeon]

Background

checkPasswordStrength enforces bcrypt's 72-byte input limit using Go's len(password), which counts bytes. However, the error message says Password cannot be longer than 72 characters, and the accompanying comment also describes a character limit.

This is misleading for multibyte UTF-8 passwords. For example, 25 repetitions of 가 contain only 25 characters but occupy 75 bytes, so they are rejected by a message that appears to allow up to 72 characters. The validation already rejects over-limit input; the bug is the unit reported to the user.

Changes

• Change the maximum-length error message from Password cannot be longer than %v characters to Password cannot be longer than %v bytes.
• Correct the bcrypt limit comment to say 72-byte limit.
• Add a table-driven regression test covering the maximum-length boundary for ASCII, Korean, and emoji passwords.

Testing

Run the focused tests from the repository root:

go test ./internal/api -run '^TestPasswordStrength' -count=1 -v

The new test covers these inputs:

Input	UTF-8 length	Expected result
a repeated 72 times	72 bytes	Accepted
a repeated 73 times	73 bytes	Rejected
가 repeated 24 times	72 bytes	Accepted
가 repeated 25 times	75 bytes	Rejected
😀 repeated 18 times	72 bytes	Accepted
😀 repeated 19 times	76 bytes	Rejected

For every rejected input, the test asserts HTTP 400, the validation_failed error code, and the exact message Password cannot be longer than 72 bytes.

Verification performed with Go 1.27.0 in the repository's Docker base image:

• Before the fix, the new test failed for all three over-limit cases because the actual message said characters instead of bytes. All three at-limit cases passed.
• After the fix, all six boundary cases and the existing TestPasswordStrengthChecks passed.
• The gofmt -s formatting check and git diff --check passed.

Review Notes

• This change corrects the maximum-length wording only. It does not alter the length check, hashing, HTTP status, or error code.
• The new tests call checkPasswordStrength directly and do not require a database. They verify validation and error fields, rather than end-to-end HTTP responses.
• Full database-backed tests were not run.
• Clients that match the exact English error message may need to update their expectations; the structured error code remains unchanged.