I believe that the only way to 'convert the BT signal to USB' would be to pair it with a BT transceiver that then reaches your host device by USB - a Bluetooth dongle, basically.
The BT communications that come in and out of the radio on the MCU inside of the keyboard do so according to the distinct two-way protocol that is Bluetooth, and it's going to work differently based on the kind of relationship - the specification sets out a range of possible configurations for each 'scenario', and BT caters to many different scenarios.
What I mean is - as an example - when your keyboard pairs with a Bluetooth transceiver, they don't just greet and start speaking Bluetooth. Once they're in range and broadcasting that they're looking to pair, if they're doing so via compatible broadcast protocols then one, or both, or neither of them will present the user with the option. Some devices do a kind of dumb pairing where they'll automatically pair with any other nearby device that is also in pairing mode and of the appropriate general device type.
It only gets more convoluted as they pair and establish their various capabilities (things like frequency hopping), device class, type, how they're going to reconnect in the case of a time-out or lost connection, etc etc
The point is, while the Bluetooth HID framework does borrow a lot from (e.g. adopting a host-slave relationship in most cases) and in some respects directly mirrors USB HID (Bluetooth HID SDPs are conceptually the same as device and interface descriptors from USB HID and even use identical formatting and definitions, making the tables interchangeable), the underlying communication method of a bi-directional link between two radio transceivers is on Neptune when considered aside the earthly USB protocol - fundamentally a host-slave relationship that happens over a single two-wire data line.
I write all this mainly to illustrate that I wasn't being glib in the first line - without some absolute black magic, PhD-worthy logical/electrical simulation of BT communications, converting BT to USB basically means using a BT dongle in the normal way.
(I also write it because articulating what I think I understand about this stuff helps me understand it better)
Anyway, as for a practical solution, in your shoes I would look at a QMK-based solution using a Pro Micro. Basically, you'll need to handwire each switch into a matrix of rows and columns with diodes at certain points along the signal path. Rows of switches soldered in series with diodes allows you to connect the 60-70+ keys to the controller's 17 pins electrically in a way that, once the matrix is defined in the QMK firmware, each key can be distinctly registered by the controller despite many keys sharing a pin. It sounds daunting, but all you really need to understand is that by defining this matrix and implementing diodes in the established way for QMK, you don't need a controller with 60 or more GPIO pins in order to have a keyboard with 60 keys. Thanks to stuff like QMK and all the brave keyboard hobbyists that came before us, wiring and defining a key matrix is a process that's surprisingly straight-forward, for which there are countless well-written guides available.
Here's a guide you can follow that should cover almost everything you need to know for this project:
https://yarukizerogames.com/wp-content/uploads/2021/09/handwired-keyboard-guide.pdf
What isn't covered are the practical adaptations you'll need to make given the somewhat unique nature of what you're doing - rather than mounting switches into a plate and then hand-wiring the matrix to the controller, your switches are already soldered into a PCB (which you will use as a plate), you already have a case, and the terminals for your switches are likely going to be very different to standard mechanical keyboard switches.
Each switch will, I'm sure, have two terminals that you can wire up to, but without knowing/seeing the switches as they are on the board, it's impossible to say how difficult/unusual this will be to perform. If they're rubber-dome/membrane keys, then the key itself is just a silicone actuator with a conductive pad that gets pushed down to the PCB, bridging a connection between two flat terminals on the face of the PCB. In that case, you'll probably have to try to wire each key up by soldering your wires to the outer edges of each flat terminal on the PCB face in a way that doesnt interfere with the rubber-dome or its conductive pad. Dome comes down, bridges two terminals, connects your wires together - that functions electrically the same as a mechanical keyswitch.
The best-case scenario is one where the keys on the keyboard use a key/switch type that is soldered to the PCB using through-holes. The pins protruding out of the back-side of the PCB will then be your terminals for the purpose of hand-wiring.
There are other possible scenarios where your terminals will be on the face or back-side of the PCB and will be less or more accessible if at all, at the end of the day there are just so many ways to make a momentary switch - feel free to send some photos of the exposed PCB and I'll do my best to help you figure out how the keys work/how to wire to them.
Lastly (I know), because the keys are electrically connected already through the PCB, you may be in a situation where you need to rip up the traces on the board running between the keys in order for the matrix to scan and register keypresses properly in QMK. This would be a pain, but the alternative would be to forgo hand-wiring and instead reverse-engineer the existing matrix on the PCB, which could work any number of ways (including some that QMK doesn't cater to), and would probably require some truly painful solder work where you're splicing diodes into the existing circuit, by exposing and soldering to the delicate traces on the board without damaging them.
If it were me I'd go the comparatively idiot-proof route of bypassing the existing matrix circuitry altogether - put wires between the bits what need wiring together and chop wires between the bits what don't
Good luck!
