So after mulling over a few options, it looks like it's best to do the decoding on a dedicated microcontroller and send a decoded LCD frame buffer periodically to a Bluetooth controller, which can then send this data to a client at its own leisure.

This solution means that there is no interruption to the high priority interrupts required to capture all the LCD instructions (which happens on the NRF52 when Bluetooth is operational). If you miss any of these instructions coming in, the decoded image can become corrupt, as each instruction either tells it which column/page to write in or which pixels to write.

The sending of data over a UART connection from the decoding chipset to another Bluetooth controller will not interfere with this, as it will send bytes "when it can" between LCD instructions. This transmission happens as a simple start sequence, then sequentially reading out each display byte and finally a CRC check. This is then buffered by the Bluetooth controller and sent to a client periodically. This framebuffer is essentially the bitmap of the image, so the client doesn't require anything fancy to decode it.

For the prototype it's still using the Feather for the Bluetooth comms, but it now also has as a Teensy for the dedicated LCD decoding:

The final version will consist of a much more simplified board containing an NRF52 chipset for Bluetooth, a SAMD21 for the LCD decoding, some level converters and a power supply. Something along the lines of this:

The code is "mostly" working on the prototype, but it still requires some testing. There was some issues building BLE support into the Visual Studio demo application so the data could be visualised. But that for the most part is working now with the help of the Universal Windows Platform, Windows.Devices.Bluetooth classes: