REQ3: On-ramp and off-ramp providers and funding modality

[filvecchiato]

Requirement for Release 2.

The problem

PaymentTopUpSource assumes the product already holds the money. A user who hits
InsufficientBalance has reached a dead end: nothing in the protocol moves value from
the outside world into their CASH balance, so the product can only report the failure
and stop. In the other direction there is no path at all — value cannot leave.

There is also no declared contract for who can move that value, so every provider
integration lands as bespoke host code rather than as a product declaring what it
serves.

What has to be true for Release 2

Moving value

• A user can move value in, from the outside world to their CASH balance
• A user can move value out
• A product declares a funding intent and watches it through to a terminal state
• A funding session survives a host restart
• The user is never told value arrived before it actually did

Providers

• A product declares the funding modality it serves in its manifest, and serves
  intents addressed to it
• The host builds its funding source list from dotNS records alone, before any
  provider code runs
• Routes are declared statically in the manifest, so the rail list needs no provider
  code
• Rails are expressible across cash, bank, card, friend, exchange and foreign-chain

Everywhere

• Works on every host that claims support

Delivery is staged

The requirement is the whole surface — both directions and the provider system. It is
delivered in stages, and the stages live in the feature issues, not here. A stage
landing narrower than this requirement is expected; the requirement is not amended to
match it.

[filvecchiato]

Closing in favour of the category trackers. Release 2 work is now split by workstream rather than by requirement.

This requirement is absorbed by #623 — Funding modality, which restates it and holds the features that satisfy it: #479 (RFC, source PR #339) and #489 (funding executable type, source PR #458).

The requirement statement above is preserved here; #623 carries it forward, including the blocking gap that the first funding increment — getsome, on-ramp, safety net — still has no issue.