[feature]: detect external spend of co-owned asset

This is mostly relevant for multi signature assets, where either the BTC-level or asset-level key are multi signature or special scripting conditions.

Today, we only mark an asset as spent when we create a transfer to spend it locally.
But in a scenario where we have a co-owned asset (e.g. multi signature) in our database but the other party spends it, we don't ever set our asset to spent, even though we could easily detect the spend of the on-chain UTXO.
Example cases:

• The asset channel funding transaction is imported into both parties' databases. But only one party will create a transfer spending it (either a force close or cooperative close transaction), on the other side it might remain as showing unspent
• MuSig2 asset swaps: Funds are deposited into a muSig2 deposit output. Depending on who spends it, the other party might not detect the spend

Steps to completion:

• Choose an appropriate component to add this functionality to (perhaps the tapgarden.Custodian? Or a new component?)
• On component startup, list all currently unspent assets and extract their anchor transaction
• Register spend notifications for those transactions. On spend, update the asset table (check transfers first, see below).
• Allow other components to register new assets to watch for (e.g. the freighter or on manual proof import)
• Make sure this component doesn't interfere with the asset store's logic that is called by the freighter, otherwise new assets might not be created correctly
  • When attempting to update an asset to spent in the database, first make sure there isn't a pending transfer that attempts to spend that asset. If there is, don't do anything and let the freighter do the update.

Start by reading tapgarden.Custodian and the asset store logic in tapdb/assets_store.go around line 3045, then trace how unspent assets and on-chain spend notifications are handled. The completed work should watch existing and newly registered asset anchors, mark externally spent assets correctly, and avoid overriding pending transfers that the freighter will update.