Since you know that your plaintext tokens are unique (or at least this is a logical inference) you don't need a salt. The salt's intention is solely to provide hash-uniqueness in the case of identical passwords, but since your input space is intended to be guaranteed unique, you don't have this problem.
Additionally, since you have control over the randomness and size of the plaintexts, you don't need to worry about weaker passwords being cracked through traditional means, so bcrypt isn't really necessary to slow down the process. If your input space is large and random, you can just hash it with a strong cryptographic hash (e.g. SHA256) with no salt. This allows you to simply check if
H(token) is in the database when generating a new token (uniqueness check).
The process for validating a reset request is then quite simple: take the user ID and the plaintext token (as supplied in the reset link) and check that they match up in the database by computing
Alternatively, if you still want to use bcrypt, you could ensure uniqueness by prepending the random token with the user ID before putting it through bcrypt. This doesn't require you to verify uniqueness (it will always be unique due to the ID prefix) and still allows you to verify the token just fine.