Introducing new PasswordHasher interface alongside PasswordEncoder

Expected Behavior

A PasswordEncoder interface should exist as the correct abstraction for password hashing operations, with PasswordEncoder depricated in its favor. The new interface would carry the same contract (hash() and matches() methods) but with naming that accurately reflects the one-way nature of the operation.

Current Behavior

PasswordEncoder is the only interface for password hashing. The name implies a reversible encoding operation, but it obviously is a one way operation or should be, if not. This is probably a semantic mismatch. Encoding is by definition reversible, hashing is not. The current naming causes confusion for developers learning Spring Security, as they must understand why a "password encoder" is used for something that is explicitly not encoding.

Context

This misleading name creates a source of confusion for developers new to Spring Security. Developers are taught that passwords must be hashed (not encoded, not encrypted) for security reasons and imagine then immediately told to implement PasswordEncoder. The contradiction requires extra explanation that should not be necessary.

The proposed change is non-breaking:

• Introduce a PasswordHasher interface with the same contract
• Deprecate PasswordEncoder pointing to PasswordHasher as its replacement
• Existing implementations and code continue to compile and work unchanged

Start with the existing PasswordEncoder interface and its hash() and matches() contract, then inspect current implementations and compatibility coverage. Determine how a PasswordHasher replacement and PasswordEncoder deprecation would preserve existing code. Done means the new abstraction is available, the old name remains compatible and deprecated, and the relevant tests pass.