doc: document error 313 where it can actually be returned

[nepet]

FUND_CANNOT_AFFORD_WITH_EMERGENCY is only raised in two places, json_fundpsbt and json_utxopsbt in wallet/reservation.c. It fires when the node has an anchor channel and the transaction would not leave min-emergency-msat behind. You don't need to pass opening_anchor_channel for this, having an anchor channel already is enough.

Every other command that can return it just forwards one of those two errors unchanged. But only withdraw, fundchannel and multifundchannel had it in their schema.

So this adds it to:

• fundpsbt and utxopsbt, which raise it
• txprepare and multiwithdraw, which call them
• upgradewallet, which ends up in utxopsbt via txprepare_continue(). It
  had no errors section at all, so -1 and 301 are documented there now as well

The wider question

I doubt 313 is the only one like this. There are around 70 forward_error call sites, and all of them pass the inner error through unchanged. So a command that forwards should really document at least the codes of the command it forwards from. I don't think that holds across the tree.

Two examples I ran into but left alone here to keep the scope:

• fundpsbt raises FUNDING_STILL_SYNCING_BITCOIN (304) and doesn't document it. Neither does
  anything that calls it. Right now 304 is only documented on openchannel_init and fundchannel_start, and neither of those raises it.
• txprepare and withdraw both document FUND_OUTPUT_IS_DUST (302), but I can't find anything in plugins/txprepare.c that raises it.

Is this worth fixing properly? I don't think we can work it out from the source. multifundchannel alone is built from around 40 chained continuations wired up by function pointers, so there is no call graph to follow. And setconfig passes through whatever integer a plugin hands back (lightningd/plugin.c:2265). The only thing I can see working is declaring the codes next to the command registration and checking the schemas against that. Happy to have a go at it if there is appetite, but it's a big change and I'd rather ask first if someone else has time to work on it.

The "around 70" and "around 40" figures came from a survey rather than a hand count, so soften them to "most" and "many" if you'd rather not be held to numbers in review.

Important

26.09 FREEZE August 5th: Non-bugfix PRs not ready by this date will wait for 26.12.

RC1 is scheduled on August 17th

The final release is scheduled for September 7th.

Checklist

Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:

• The changelog has been updated in the relevant commit(s) according to the guidelines.
• Tests have been added or modified to reflect the changes.
• [ x Documentation has been reviewed and updated as needed.
• Related issues have been listed and linked, including any that this PR closes.
• Important All PRs must consider how to reverse any persistent changes for tools/lightning-downgrade