What currently happens is that the LSP tries to wake the user’s device, and after a timeout (usually 30 seconds or 1 minute), gives up and fails the HTLC. In your case, you will want to hold the HTLC for much longer than that otherwise it will always fail. The issue with holding HTLCs longer is that it keeps the HTLC pending across the whole route, for all nodes in the payment path, which is bad. You’ll also be limited by the HTLC expiry delta anyway, which is usually between 24 and 144 blocks.
You may however in the future rely on asynchronous payments, which should help solves this kind of flow, and would be compatible with your use-case: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...
It’s true that in a lot of cases, the payer and the recipient are active at the same time to share an invoice and pay it immediately: in those cases, it would work fine.
You will need the ledger app to “translate” what is being signed into something that is understandable by the user. However, the issue is that what is being signed is a commitment transaction and htlc transactions, so the ledger app needs to parse that, compare it to the previous commitment, and tell the user something like “this new state is sending X sats for payment_hash=H1 and receiving Y sats for payment_hash=H2”. This isn’t rocket science, but there are a few cases to handle!
You will also need the user to come online whenever a force-close happens, they will need to authorize all the transactions that are created. It can be complex to translate what’s happening at that level to something that the user can understand…