Persist payjoin receiver sessions across restarts

[chavic]

Summary

This makes Payjoin receiver-session state durable enough for milestone one so active negotiations can survive a BTCPay restart and replay deterministically enough to keep progressing.

What changed

• add plugin-owned ReceiverSessions and ReceiverSessionEvents persistence tables plus the EF migration
• replace the in-memory receiver session store with a database-backed replay store
• persist the contributed receiver input metadata needed to resume replay beyond WantsInputs
• persist close-request and invoice-status lifecycle metadata instead of keeping it only in process memory
• start plugin migrations before the poller and lifecycle hosted services so recovery runs against migrated tables

Why

The previous implementation kept receiver negotiations in memory. A restart lost active session state and made recovery non-deterministic, which is below the milestone-one durability bar.

Impact

• active Payjoin negotiations can be reloaded from the plugin database after restart
• the Payjoin URI path can create or reuse stable session state instead of rebuilding it only in memory
• cleanup removes both session metadata and the ordered event log, keeping lifecycle handling restart-safe

Validation

• reviewed the persistence and replay path changes end to end in the plugin diff
• attempted dotnet build BTCPayServer.Plugins.Payjoin/BTCPayServer.Plugins.Payjoin.csproj -p:NuGetAudit=false
• build verification could not complete in this checkout because the referenced BTCPayServer project tree was missing (btcpayserver/BTCPayServer/BTCPayServer.csproj)

Follow-up

A full checkout still needs:

• a restart scenario where an active receiver negotiation resumes through replay