[feature]: allow inbound keysend an asset from a remote node that sends sats

This issue addresses the opposite scenario of https://github.com/lightninglabs/taproot-assets/issues/1443 .

Currently we have the ability to keysend an asset directly to a peer over a taproot asset channel from Alice to Bob where Alice sends assets and Bob receives assets. This doesn't require any RFQ since there is no asset conversion.

         TA
 Alice <----> Bob
         SAT

What we do not have is the ability for Alice to keysend sats and Charlie receive assets.

                    TA
 Alice <----> Bob <----> Charlie
         SAT        SAT

Currently for Charlie to receive assets when Alice sends sats through Bob, Charlie must perform an RFQ with Bob and assign a SCID to the quote. That SCID is then put in an invoice that is given to Alice. When Alice tries to pay through Bob to that SCID, Bob and Charlie know that assets are to be sent instead.

With keysend, we don't have the ability to receive taproot assets when paid from a non-direct peer. This is because of a few reasons:

• Taproot asset channels are currently private channels: Alice won't know about the channel to be able to keysend to it. However, if https://github.com/lightninglabs/taproot-assets/issues/1254 are fixed and we have non-trivial amount of sats in channels, we may want to make taproot asset channels non-private and use them as regular routing channels as well. In that case, Alice could know about the channel and try to keysend sats to it, but not know that it had taproot assets in it.
• We don't have a pre-negotiated RFQ and an ephemeral SCID tied to an RFQ since Charlie doesn't even know Alice wants to pay him. What we could do though is have a special flag on Charlie that he can enable that says that he wants all payments coming in on a real SCID to be received in taproot assets instead of sats. This would require for each in flight HTLC to be paused and wait for an RFQ to be negotiated before the HTLC is accepted by Charlie. This could then allow Charlie to receive taproot assets via keysend without Alice even knowing Charlie is receiving taproot assets.

This feature would allow services that currently rely on keysend to receive taproot assets instead of sats without any change in workflow to the senders or the architecture of application/service that is being provided.

Start by reviewing the related issues 1443 and 1254, then trace the keysend, RFQ, ephemeral SCID, and inbound HTLC flow in the Go daemon. Done means a remote keysend of sats can cause the recipient to receive taproot assets without a pre-negotiated RFQ or sender workflow change, with the proposed payment behavior covered by tests.