if anyone wants to prepare a really calm and well written issue for them and see if they will just be reasonable, here are links for all the places you can point to where users passwords and/or hashes of them are being handled in manners contrary to their intended use, and ask that this behavior AT LEAST be gated by an opt-in toggle.
and not just the API call to HIBP, but also the collection of users secrets and subjection of them to checks users did not get the chance to offer informed consent to.
where HA Supervisor's pwned check sends a hash of a collected password to HIBP: https://github.com/home-assistant/supervisor/blob/main/supervisor/utils/pwned.py
where the function above is called: https://github.com/home-assistant/supervisor/blob/main/supervisor/security/module.py#L45
where verify_secret is called, two locations: https://github.com/home-assistant/supervisor/blob/main/supervisor/resolution/checks/app_pwned.py#L53
verify_secret called here as well: https://github.com/home-assistant/supervisor/blob/main/supervisor/api/apps.py#L411
here, in at least _single_validate and _validate_typed, a users password is handled in plaintext prior to hashing with SHA1 and truncated: https://github.com/home-assistant/supervisor/blob/main/supervisor/apps/options.py#L167
it took me about a non-contiguous two hours and zero tokens to reach the conclusion that because this Supervisor component runs as a docker container on the host and operates via a REST API, like, here where validate options route includes calls to some of the above functions: https://github.com/home-assistant/supervisor/blob/main/supervisor/api/__init__.py#L775 that something else is doing the collecting here and it will take me some more non-contiguous hours to figure out where all this is happening and discern a good way to rip it out.
OR
the developers of this software who are far more familiar with it and responsible for it could be reasonable and put this kind of malicious-anywhere-else behavior behind an opt-in toggle.