This system works, though it's needlessly expensive for your server. Bcrypt is designed for low-entropy inputs that are stored long-term where there's a risk that an attacker will see the digest. That doesn't apply here; the bcrypt digest is technically low-entropy but not dangerously so on the timescale in question (I assume you're looking at a very narrow window, since you mention expiry in "minutes"), and if the attacker could breach the reset token this way they wouldn't need it anyhow (they'd have the password). Besides, you're not storing the result anyhow.
A simple hash (a single round of SHA256 or similar, over the current password hash) is perfectly sufficient and much less computationally expensive. If you want to avoid multiple reset tokens having the same secret in them even when one isn't used, you can salt the hash with a random value, but I don't think that actually adds anything; the actual secret is the JWT signing key and you could, in theory, leave the hash of the password hash out of it entirely! The only reasons to add it are to invalidate existing password reset tokens once the password changes, and to make it more difficult to forge the reset tokens if your signing key leaks (only relevant if your signing key is not also used to sign access tokens). Neither of those uses care whether the hash value is the same across multiple tokens for the same user or not. There's certainly no benefit to using a consistent field (like the userid or creation timestamp) as a salt.
The conventional approach here, assuming you can't alter the existing table, is just to create a new one for the reset tokens. The new table would be indexed (uniqueness optional) on a foreign key to the existing users table - typically either the userid or email would make sense, assuming duplicate emails aren't allowed - and additionally contain a hashed random secret (which need only be a single round of unsalted secure hash function) and an expiry. The actual password reset tokens would only have two parts, the identifier (whatever you indexed the password reset table on) and pre-hashed secret (generated on-demand via CSPRNG for each token). Upon successful reset, you'd just
DELETE FROM PasswordResetTokens WHERE TokenId = @id to invalidate any copies (or additional tokens generated for that user, if you allow multiples). A scheduled job could periodically wipe out any tokens that have expired just to keep the table size small.
Given that a password reset operation needs to interact with the DB anyhow, and isn't something you can meaningfully load-balance, there's really no advantage to making the reset token a JWT unless there's extra metadata you want to stuff in there. Even if you're already using JWTs elsewhere, such as for the session/access token, adding more seems like needless complexity. Of course, that assumes you can create a DB table; if you can't do that and can't alter the existing one, then this approach might be next best.