Presumably I should read through the bitcoin dev mailing list to figure out how the developers imagined using a pruned node would work.
I don't see a way around requiring a pruning node to redownload the entire blockchain whenever a wallet is imported. Presumably this might end up as the accepted way of doing things, users should recover or import new wallets rarely.
One thing I've been thinking myself recently is this: As you say, it is actually enough to work through the UTXO set when looking for the balance of some address you try to import. So this should, in theory, be possible with a pruned node without redownloading blocks (your suggestion 2 above). I do not know what the developers think about making use of this, maybe it is already on their plan - the only "issue" is that you won't get a wallet with full tx history, "only" the full balance. But that seems to be fine for your usecase. One could add a new RPC call that lists the full UTXO set (as you suggest), or even just add a "light" address importing mode that only checks the UTXO set instead of the full blockchain. This is not too hard to do, and I think that I could actually do it myself if there is any chance for it to be merged upstream.
Another suggestion: As far as I can tell, the addresses you are going to import are most probably fresh ones. Why not import them without any rescanning at all? At least as a temporary and optional measure.
(By the way, I'm actually using a pruned node with JoinMarket on a VPS right now. It works fine in normal operation, but I do have nodes with full history ready that I can use for importing more addresses when necessary.)