feat: allow payer to settle payment rails

[SgtPooki]

Description

A payer can settle their own payment rails, not just the storage provider. Today filecoin-pin neither surfaces pending settlements nor offers a way to settle from the CLI.

This is a convenience, not a necessity: SPs settle their rails at least every lockupPeriod (30 days for WarmStorage). A client may still want to settle for accounting or to keep balances current.

Scope

The SDK already supports both halves (synapse-sdk payments.settle() and payments.getSettlementAmounts()):

• Surface pending settlements in payments status: query getSettlementAmounts across the payer's rails and show what is settleable.
• Add a payments settle [--rail <id>] command that settles via payments.settle().

Done criteria

• payments status shows pending/settleable amounts per rail for the payer.
• payments settle settles a payer's rail(s): --rail <id> targets one, default settles all settleable.
• Output reports the settled amount and final settled epoch (SettlementResult).

Notes

Low priority. SPs and Curio tooling handle settlement in the normal path; this is a client-side convenience.

[BigLep]

Good callout @SgtPooki . It doesn't seem like blocking for this week, so will let @rvagg weigh in when he's back.

[rvagg]

It's a convenience rather than a necessity that clients settle rails - if an SP doesn't want to take my money then I won't force it on him! But there might be good reason to get your rails settled up yourself, for accounting, or because you're OCD about such things. An SP should be settling their rails at maximum each lockupPeriod epochs. So for WarmStorage, every 30 days or less. Then they can know whether the client is about to go insolvent, or has ordered termination, and not be in a loss situation.

It might be neat to have a client-side tool to settle, SPs could potentially even use it too, although they should be getting Curio utilities and UI to manage all of this. So we can add something, but it's low priority.