Fix Recover button action resolution in funded projects

[SuperJMN]

Summary

This PR fixes a bug in the Recover flow by using IDialog.ShowAndGetResult properly.

In practice, this makes the Recover button behave more reliably because the UI and the command execution path now follow the same source of truth.

Also, the FundedBase, that is a ViewModel after all, was handly too many responsibilities, something that is damaging testability and maintainability.

What changed

• introduced RecoveryActionKind to make the available recovery actions explicit
• introduced RecoveryActionPolicy to centralize recovery-state-to-action resolution
• updated FundedCommandsFactory to consume the resolved action instead of spreading the decision across several condition blocks
• removed button-label logic from RecoveryState, leaving it as plain state data

Why this is the right direction

This is more than a bug fix.

The previous flow mixed raw state inspection with action selection in multiple places, which made it easier for the Recover button to present one thing and execute another. With the new policy-based approach, the same action resolution drives:

• whether recovery is available
• which label is shown
• which dialog title and success message are shown
• which transaction builder is used

That gives us better responsibility boundaries and a much more testable shape. RecoveryState stays as data, while RecoveryActionPolicy owns the decision logic. That separation should make future recovery-related changes safer and easier to verify.

Validation

• dotnet test AngorApp.Tests/AngorApp.Tests.csproj --no-restore
• Result: 47 tests passed