I think in order to implement that, all sensitive reports would have to be left out, plus the original victim should also get an e-mail with a clearly visible red banner in the top "This e-mail has also been sent to Troy <email@example.com>."
From your blogs I think you are using a Key, Value data structure, which means when a query comes, your data store needs an exact *key* to find the value (if it has been breached or not). That's probably the best data structure for HIBP since it can scale infinitely, however it will not allow you to query firstname.lastname@example.org.. I guess the only way to address that is to either canonicalize the data as you add it, by removing everything after "+" (or ".", or "-"), which means this will only work with new data sets, or change the table schema / contents of "Value", which is very unlikely to happen.. Another solution would be to create a new "table" with all e-mails with "+", ".", or "-", and then query both when someone requests information, only that this time you format the "Value" of those "Keys" accordingly.. Although it may seem like a lot of work, the earlier it is done, the better it will be as it will include more datasets..
Typically, when an account is breached, it is recommended to change your password there immediately, if not done already by the provider, and then change your password to every service in which you used the same one.
In general, a safe practice is to have a different password in every website, that is difficult to predict if one is compromised. For example, while "apq3984!#$dDF-adobe" is a good password in general, if an attacker can read it in the clear, then they will try "apq3984!#$dDF-ebay" on your eBay account, etc. Since managing so many passwords is not easy, it is recommended to use a Password Manager, like 1Password.
Currently not all breached include a phone number, but all contain an e-mail address. Searching for a phone number could give the "illusion" that you're safe, while you may be not.
Let's wait for Troy to learn more.