Did you read the bit of the data sheet telling you that the reset pin shouldn’t be driven high, it should only ever be connected to an open drain driver?
Remove all the connections other than the SPI bus, power and ground. The rest aren’t needed for basic comms.
Set the SPI bus speed to 100kHz.
Drive chip select low, send 5 bytes of 0x00 on the SPI bus and see what you get back.
If all you see is 0xFF (which should be the default idle state of the bus) then you have a fundamental issue with the part, either it’s not connected correctly or it’s not getting power.
You checked the MISO line and it’s always idle. Did you check the other SPI lines? Are the clock and MOSI lines acting as expected? Is their timing correct relative to each other and the falling / rising edges of the CS lines?
As a side not generally a Pi running python is not a good choice of host. You can certainly go that route if you want, for a university project it’s good enough. But you’re not going to get the best in terms of accuracy or update rate, it’ll be too slow and variable in timing for that. UWB ranging doesn’t need much processing power but the faster you can respond to things the better, neither linux or python make for fast responses.
But it does give you something to put in possible future improvements part of the write up 