feat: deep link the late transfer screens

[guzino]

Refs #659
Refs #1119

#1119 denies six transfer destinations because their generated links do not reconstruct the state the screens read. This issue tracks direct support for them.

Denied today

Route	State it reads
SavingsProgress	the active transfer, and it can act on default or retained channel state
SettingUp	the paid order the funding step created
SpendingAdvanced	the order being adjusted, opened from SpendingConfirm or SpendingHwSign
SpendingConfirm	the composed order and fee estimate
SpendingHwSign(deviceId)	the composed transaction plus a paired device
SpendingHwSigned	the signed transaction and its broadcast result

All six read transferViewModel, which is scoped to the activity rather than to the route. A fresh link therefore renders empty state, returns home, or acts on whatever the previous flow left behind.

Setup contract

Each screen needs a per-flow contract that runs before navigation:

1. Prepare the state the preceding user and app actions would have produced.
2. Perform the server-side preparation the step depends on, using the lsp skill for Blocktank orders, deposits and channel opens.
3. Pass stable identifiers as route parameters rather than relying on retained view model state.
4. Reload and validate that data before navigating, and refuse the link when validation fails.

SpendingHwSign already carries deviceId, so it is the closest to the target shape and the smallest first slice.

Done when

• Each of the six is reachable from a cold start and renders the state its identifiers name.
• A link whose identifiers no longer resolve is refused with the existing Unhandled screen deeplink warning rather than rendering empty.
• SavingsProgress cannot execute against retained channel state.
• The routes are removed from DENIED in ScreenDeepLinks and from SENSITIVE_ROUTES in ScreenDeepLinksTest, and docs/deeplinks.md moves them out of the excluded table.