I can confirm that it is possible to run LOS 1.x on Lisa 2/5's. When I bought my X/ProFile from vintage micros, CF cards containing LOS 1.2 or 1.1 were included and these boot without issue. But ofc, 870KB disks won't be accessible as the hardware just isn't there.
That said you'd absolutely need a working Twiggy drive to image these using BLU. Once that data is recovered in dc42 format, whatever steps are next could be taken. But the first and most important step is to read the media successfully.
Even if your existing media might be bad, using BLU you could create copies onto modified 5.25" HD disks (so they can fit in a twiggy drive and have the extra data window) and then attempt to install them to a ProFile and them image that profile.
I don't know about LOS 1.x. but I do have a tool deserialization program in LisaEm 1.2.7 that can be used.
Basically there's a "Protect" flag that's enabled on the equivalent of the inode like extent blocks block that can be disabled. I can't say whether or not this is in the same location for LOS 1.x vs LOS 2.x/3.x, but that can be found out with experimentation via LPW. i.e. you can copy an unprotected tool/application to/from twiggy media and image it and look at the inode like extent blocks. These extent blocks have the same file id as the block number they live on minus the OS boot blocks, but they are 2's complemented. So it's easy to find them as tag bytes 4,5 as a 16 bit word are negative.
So if the file ID is 15, you'd see tags 4,5 in two's complement form of the number 15, and these would live 15 blocks after the MDDF (superblock), and so you'd see FF F1 at tag positions 4,5.
This code is used to null out the bozo bit (aka protect):
https://github.com/rayarachelian/lisaem/blob/09afe9e998752d4458d8c9d1fdab2c562a4c628e/src/tools/src/los-deserialize.c#L55
So likely LOS 1.x has a very similar flag somewhere in that block for serialization, possibly at a slightly different position. But again, you can do something like copy the clock or the preferences app to FileWare, dump that out and then try it with a protected tool such as LisaWrite or LisaCalc and see if you see extra bits turned on in the extent block.
I can probably spend a couple of hours with the existing twiggy disk images off bitsavers and the X/ProFile disk images of LOS 1.x myself and figure this out.
But there's a couple of more important things to worry about:
1. is how is the virus affecting affecting postal service between Switzerland and The UK.
2. Is Brexit going to be an issue in terms of how fast packages can get through.
3. How do you safely protect the twiggies from being erased by magnetic fields as it passes through the postal systems/customs? - I'd suggest wrapping them in two boxes with lots of space between the outside box and inner box, and then wrapping the inner box with aluminum foil to create a faraday cage. But not sure if this will cause customs to mess with the package and when they open the package somehow damage the media itself. The two box method will provide distance from the outside to the inside thus lowering the magnitude of any magnetic fields from motors. Wrapping the inner box with foil will help deflect the rest.
You'd want the inner box immobilized inside the outer box, this would mean using very tight bubble wrap rather than air filled bags.
I'd also mark the outside with "Magnetic media enclosed." but that might not mean much to postal employees anymore.
If you're going to send Tom your twiggy media, and he's willing to image it, (I'm making two large assumptions here) I'd do it sooner rather than later before it gets even more difficult. Again, we can worry about how things are installed on ProFiles or deserialized later. It's far more critical to get the media imaged first.
Once it's imaged, you practically have all the time in the world to mess with it and analyze it.