Core Lightning

bookkeeper: honor start and ent times when consolidating onchain fees.

Fixes: https://github.com/ElementsProject/lightning/issues/8318

Reported-by: Shahaha
Changelog-Fixed: Plugins: `bkpr_listincome` now honors `start_time` and `end_time` parameters for onchain fees.

bookkeeper: save last timestamp to avoid another query in find_consolidated_fees.

If the fees are not *all* of the fees (as we do in next patch), the
query would be wrong. Plus, as the FIXME suggests, we should just save
it as we're getting the fee_sums, not do a whole new query!

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

pytest: test (failing) for bkpr-listincome filtering times on onchain events.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

gpg: Updating Shahana's expired keys

Also added Madeline's missing keys on security-policy page.

Changelog-None.

Meta: Adding changelog and version update for 25.09.1

doc: Add step for point release checklist to merge updates from `update-versions` and `CHANGELOG.md` into `master`

Changelog-None.

plugin: fix feature_set allocation

Using `tal_dup_or_null` does not set the tal context to the included
bytes array. Luckily we already have a function tha deeply duplicates
a `feature_set`: `feature_set_dup`

Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>

test: refactor plugin to use parameter not envvar

Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>

test: check that features get removed when ...

a plugin is disabled during init.

Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>

tools: Read the correct default-key from gpgconf

Workflow error `gpg: using "4129A994AA7E9852" is thrown due to incorrect gpg parsing. Update the awk parsing logic to properly locate and extract the key fingerprint within the gpgconf --list-options output structure, ensuring automated signing uses the correct key.

Changelog-None.

makefile: enable fuzzing support on macOS

Enable fuzzing support on macOS by configuring the build system to use Homebrew LLVM toolchain and handle macOS-specific linking requirements.

The `make check-fuzz` command was failing on macOS because:
- System clang lacks fuzzer runtime library support
- Linking issues with fuzzer targets
- Test script attempts to execute debug symbol files

This PR adds macOS-specific configuration to:
- Use Homebrew LLVM toolchain for fuzzer support
- Explicitly link fuzzer libraries
- Exclude `.dSYM` directories from test discovery

All 76 fuzzer targets now build and pass on macOS.

bookkeeper: only read listchannelmoves 1000 entries at a time.

If we read all of them, we might get 1.6M at once (after initial
migration). Then we submit a few hundred thousand simultaneous
requests to lightningd, and it gets upset, queueing them all on the
xpay command hook and running out of memory.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: plugins: bookkeeper first invocation after migration from prior to 25.09 with very large databases will not crash.

libplugin: remove redundant destructor which causes exponential slowdown on large numbers of requests.

Note that we create a destructor on the command to reset request->cmd
pointer if the cmd is freed (so we know not to call the callback).
But attaching hundreds of thousands of them is slow: it's a
single-linked list, which is iterated in several places.

But that's redundant: the request is now allocated off the cmd, so freeing the command
will free the request anyway.

Hacking in something to print progress to a file, here's the number of
requests processed every 10 seconds before and after:

Before:
$ while sleep 10; do wc -l /tmp/bkpr-progress; done
181529 /tmp/bkpr-progress
195994 /tmp/bkpr-progress
207083 /tmp/bkpr-progress
226336 /tmp/bkpr-progress
234319 /tmp/bkpr-progress
241514 /tmp/bkpr-progress
247421 /tmp/bkpr-progress
255292 /tmp/bkpr-progress
261367 /tmp/bkpr-progress
269085 /tmp/bkpr-progress
276953 /tmp/bkpr-progress
282233 /tmp/bkpr-progress
286193 /tmp/bkpr-progress
290930 /tmp/bkpr-progress
295276 /tmp/bkpr-progress
301086 /tmp/bkpr-progress

After:
169505 /tmp/bkpr-progress
196010 /tmp/bkpr-progress
219370 /tmp/bkpr-progress
235671 /tmp/bkpr-progress
244242 /tmp/bkpr-progress
255362 /tmp/bkpr-progress
265636 /tmp/bkpr-progress
276966 /tmp/bkpr-progress
284451 /tmp/bkpr-progress
288836 /tmp/bkpr-progress
296578 /tmp/bkpr-progress
304571 /tmp/bkpr-progress

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

plugins/sql: add payment_hash index to channelmoves table.

This significantly speeds up the query which bookkeeper often does:

"SELECT created_index"
" FROM channelmoves"
" WHERE payment_hash = X'%s'"
" AND credit_msat = %"PRIu64
" AND created_index <= %"PRIu64,

On large databases this scan is expensive, and a payment_hash index
cuts it down a great deal. It does take longer to load the channelmoves
in the first place though (about 3x).

Before:
$ while sleep 10; do wc -l /tmp/bkpr-progress; done
169505 /tmp/bkpr-progress
196010 /tmp/bkpr-progress
219370 /tmp/bkpr-progress
235671 /tmp/bkpr-progress
244242 /tmp/bkpr-progress
255362 /tmp/bkpr-progress
265636 /tmp/bkpr-progress
276966 /tmp/bkpr-progress
284451 /tmp/bkpr-progress
288836 /tmp/bkpr-progress
296578 /tmp/bkpr-progress
304571 /tmp/bkpr-progress

After:
$ while sleep 10; do wc -l /tmp/bkpr-progress; done
161421 /tmp/bkpr-progress
238273 /tmp/bkpr-progress
281185 /tmp/bkpr-progress
305787 /tmp/bkpr-progress

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: plugins: the sql plugin now keeps an index on `channelmoves` by `payment_hash`.

makefile: use SED from configure in most places.

Some simple cases are left alone, but anything called from make uses $SED.

configure: set SED to gsed (MacOS et al) or sed (GNU).

We use some GNU sed features and it's easier to require gsed than fix
them all (and keep noticing when they break). MacOS comes with gsed
already!

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

pytest: fix flakes in feerates.

Sometimes we get a shorter signature than expected, and we're supposed
to disable the feerate tests in that case. But we didn't catch all the
cases where we make signatures.

```
2025-10-13T02:36:24.1901527Z ____________________________ test_peer_anchor_push _____________________________
2025-10-13T02:36:24.1902251Z [gw5] linux -- Python 3.10.18 /home/runner/work/lightning/lightning/.venv/bin/python
2025-10-13T02:36:24.1902731Z
2025-10-13T02:36:24.1903045Z node_factory = <pyln.testing.utils.NodeFactory object at 0x7f17fdffd6f0>
2025-10-13T02:36:24.1903740Z bitcoind = <pyln.testing.utils.BitcoinD object at 0x7f17fdffe830>
2025-10-13T02:36:24.1904495Z executor = <concurrent.futures.thread.ThreadPoolExecutor object at 0x7f17fdffcbb0>
2025-10-13T02:36:24.1906158Z chainparams = {'bip173_prefix': 'bcrt', 'chain_hash': '06226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f', 'elements': False, 'example_addr': 'bcrt1qeyyk6sl5pr49ycpqyckvmttus5ttj25pd0zpvg', ...}
2025-10-13T02:36:24.1907285Z
2025-10-13T02:36:24.1907600Z @unittest.skipIf(TEST_NETWORK != 'regtest', 'elementsd anchors not supportd')
2025-10-13T02:36:24.1908344Z def test_peer_anchor_push(node_factory, bitcoind, executor, chainparams):
2025-10-13T02:36:24.1909033Z """Test that we use anchor on peer's commit to CPFP tx"""
2025-10-13T02:36:24.1909853Z l1, l2, l3 = node_factory.line_graph(3, opts=[{},
2025-10-13T02:36:24.1910334Z {'min-emergency-msat': 546000,
2025-10-13T02:36:24.1910825Z 'dev-warn-on-overgrind': None,
2025-10-13T02:36:24.1911313Z 'broken_log': 'overgrind: short signature length'},
2025-10-13T02:36:24.1911662Z {'disconnect': ['-WIRE_UPDATE_FULFILL_HTLC'],
2025-10-13T02:36:24.1911976Z 'dev-warn-on-overgrind': None,
2025-10-13T02:36:24.1912304Z 'broken_log': 'overgrind: short signature length'}],
2025-10-13T02:36:24.1912790Z wait_for_announce=True)
2025-10-13T02:36:24.1913041Z
2025-10-13T02:36:24.1913305Z # We splinter l2's funds so it's forced to use more than one UTXO to push.
2025-10-13T02:36:24.1914043Z fundsats = int(Millisatoshi(only_one(l2.rpc.listfunds()['outputs'])['amount_msat']).to_satoshi())
2025-10-13T02:36:24.1914443Z OUTPUT_SAT = 10000
2025-10-13T02:36:24.1914647Z NUM_OUTPUTS = 10
2025-10-13T02:36:24.1914903Z psbt = l2.rpc.fundpsbt("all", "1000perkw", 1000)['psbt']
2025-10-13T02:36:24.1915520Z # Pay 5k sats in fees.
2025-10-13T02:36:24.1916329Z psbt = l2.rpc.addpsbtoutput(fundsats - OUTPUT_SAT * NUM_OUTPUTS - 5000, psbt, destination=l3.rpc.newaddr()['bech32'])['psbt']
2025-10-13T02:36:24.1917156Z for _ in range(NUM_OUTPUTS):
2025-10-13T02:36:24.1917638Z psbt = l2.rpc.addpsbtoutput(OUTPUT_SAT, psbt)['psbt']
2025-10-13T02:36:24.1918194Z l2.rpc.sendpsbt(l2.rpc.signpsbt(psbt)['signed_psbt'])
2025-10-13T02:36:24.1918731Z bitcoind.generate_block(1, wait_for_mempool=1)
2025-10-13T02:36:24.1919232Z sync_blockheight(bitcoind, [l1, l2])
2025-10-13T02:36:24.1919634Z
2025-10-13T02:36:24.1919847Z # Make sure all amounts are below OUTPUT_SAT sats!
2025-10-13T02:36:24.1920318Z assert [x for x in l2.rpc.listfunds()['outputs'] if x['amount_msat'] > Millisatoshi(str(OUTPUT_SAT) + "sat")] == []
2025-10-13T02:36:24.1920735Z
2025-10-13T02:36:24.1920957Z # Get HTLC stuck, so l2 has reason to push commitment tx.
2025-10-13T02:36:24.1921244Z amt = 100_000_000
2025-10-13T02:36:24.1921517Z sticky_inv = l3.rpc.invoice(amt, 'sticky', 'sticky')
2025-10-13T02:36:24.1921842Z route = l1.rpc.getroute(l3.info['id'], amt, 1)['route']
2025-10-13T02:36:24.1922277Z l1.rpc.sendpay(route, sticky_inv['payment_hash'], payment_secret=sticky_inv['payment_secret'])
2025-10-13T02:36:24.1922751Z l3.daemon.wait_for_log('dev_disconnect: -WIRE_UPDATE_FULFILL_HTLC')
2025-10-13T02:36:24.1923060Z
2025-10-13T02:36:24.1923241Z # Make sure HTLC expiry is what we expect!
2025-10-13T02:36:24.1923637Z l2.daemon.wait_for_log('Adding HTLC 0 amount=100000000msat cltv=119 gave CHANNEL_ERR_ADD_OK')
2025-10-13T02:36:24.1923998Z
2025-10-13T02:36:24.1924229Z # l3 drops to chain, but make sure it doesn't CPFP its own anchor.
2025-10-13T02:36:24.1924685Z wait_for(lambda: only_one(l3.rpc.listpeerchannels(l2.info['id'])['channels'])['htlcs'] != [])
2025-10-13T02:36:24.1925688Z closetx = l3.rpc.dev_sign_last_tx(l2.info['id'])['tx']
2025-10-13T02:36:24.1926132Z l3.stop()
2025-10-13T02:36:24.1926337Z # We don't care about l1 any more, either
2025-10-13T02:36:24.1926579Z l1.stop()
2025-10-13T02:36:24.1926739Z
2025-10-13T02:36:24.1926941Z # We put l3's tx in the mempool, but won't mine it.
2025-10-13T02:36:24.1927316Z bitcoind.rpc.sendrawtransaction(closetx)
2025-10-13T02:36:24.1927754Z
2025-10-13T02:36:24.1928139Z # We aim for feerate ~3750, so this won't mine l3's unilateral close.
2025-10-13T02:36:24.1928991Z # HTLC's going to time out at block 120 (we give one block grace)
2025-10-13T02:36:24.1929527Z for block in range(110, 120):
2025-10-13T02:36:24.1929989Z bitcoind.generate_block(1, needfeerate=5000)
2025-10-13T02:36:24.1930510Z assert bitcoind.rpc.getblockcount() == block
2025-10-13T02:36:24.1931014Z sync_blockheight(bitcoind, [l2])
2025-10-13T02:36:24.1931715Z assert only_one(l2.rpc.listpeerchannels(l3.info['id'])['channels'])['state'] == 'CHANNELD_NORMAL'
2025-10-13T02:36:24.1932368Z
2025-10-13T02:36:24.1932642Z # Drops to chain
2025-10-13T02:36:24.1933030Z bitcoind.generate_block(1, needfeerate=5000)
2025-10-13T02:36:24.1933824Z wait_for(lambda: only_one(l2.rpc.listpeerchannels(l3.info['id'])['channels'])['state'] == 'AWAITING_UNILATERAL')
2025-10-13T02:36:24.1934522Z
2025-10-13T02:36:24.1935254Z # But, l3's tx already there, and identical feerate will not RBF.
2025-10-13T02:36:24.1935839Z l2.daemon.wait_for_log("rejecting replacement")
2025-10-13T02:36:24.1936357Z wait_for(lambda: len(bitcoind.rpc.getrawmempool()) == 2)
2025-10-13T02:36:24.1936801Z
2025-10-13T02:36:24.1937127Z # As blocks pass, we will use anchor to boost l3's tx.
2025-10-13T02:36:24.1937666Z for block, feerate in zip(range(120, 124), (12000, 13000, 14000, 15000)):
2025-10-13T02:36:24.1938560Z l2.daemon.wait_for_log(fr"Worth fee [0-9]*sat for remote commit tx to get 100000000msat at block 125 \(\+{125 - block}\) at feerate {feerate}perkw")
2025-10-13T02:36:24.1939369Z l2.daemon.wait_for_log("sendrawtx exit 0")
2025-10-13T02:36:24.1939902Z # Check feerate for entire package (commitment tx + anchor) is ~ correct
2025-10-13T02:36:24.1940473Z details = bitcoind.rpc.getrawmempool(True).values()
2025-10-13T02:36:24.1940920Z print(f"mempool = {details}")
2025-10-13T02:36:24.1941347Z total_weight = sum([d['weight'] for d in details])
2025-10-13T02:36:24.1941903Z total_fees = sum([float(d['fees']['base']) * 100_000_000 for d in details])
2025-10-13T02:36:24.1942467Z total_feerate_perkw = total_fees / total_weight * 1000
2025-10-13T02:36:24.1942972Z > check_feerate([l3, l2], total_feerate_perkw, feerate)
2025-10-13T02:36:24.1943279Z
2025-10-13T02:36:24.1943411Z tests/test_closing.py:4064:
2025-10-13T02:36:24.1943813Z _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
2025-10-13T02:36:24.1944170Z
2025-10-13T02:36:24.1944685Z nodes = [<fixtures.LightningNode object at 0x7f17fdf684f0>, <fixtures.LightningNode object at 0x7f17fdf6af50>]
2025-10-13T02:36:24.1945708Z actual_feerate = 13005.66942869603, expected_feerate = 13000
2025-10-13T02:36:24.1946091Z
2025-10-13T02:36:24.1946247Z def check_feerate(nodes, actual_feerate, expected_feerate):
2025-10-13T02:36:24.1946558Z # Feerate can't be lower.
2025-10-13T02:36:24.1946870Z assert actual_feerate > expected_feerate - 2
2025-10-13T02:36:24.1947365Z if actual_feerate >= expected_feerate + 2:
2025-10-13T02:36:24.1947830Z if any([did_short_sig(n) for n in nodes]):
2025-10-13T02:36:24.1948239Z return
2025-10-13T02:36:24.1948589Z # Use assert as it shows the actual values on failure
2025-10-13T02:36:24.1949043Z > assert actual_feerate < expected_feerate + 2
2025-10-13T02:36:24.1949489Z E AssertionError
2025-10-13T02:36:24.1949704Z
```

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

connectd: close connection properly after dev-disconnect `+`.

We need to drain subds too, otherwise if timing is correct we never close.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

ccan: update to latest.

We fix the configure test which was bogus, and breaks on 32-bit gcc with optimization:

```
checking for unaligned access to int... ccan/tools/configurator/configurator: Test for HAVE_UNALIGNED_ACCESS did not compile:
configuratortest.c: In function 'main':
configuratortest.c:8:22: error: array subscript 'int[0]' is partly outside array bounds of 'char[4]' [-Werror=array-bounds]
8 | return *x == *y;
| ^~
configuratortest.c:5:11: note: at offset 1 into object 'pad' of size 4
5 | char pad[sizeof(int *) * 1];
| ^~~
cc1: all warnings being treated as errors
```

And also removes sprintf() calls, which apparently MacOS no longer likes:

Environment: Sequoia 15.6.1 (24G90)
SDK Version: MacOSX15.sdk

```
ccan/ccan/closefrom/closefrom.c:83:2: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
83 | sprintf(dnam, "/proc/%ld/fd", (long) getpid());
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:278:1: note: 'sprintf' has been explicitly marked deprecated here
278 | deprecated_msg("This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:218:48: note: expanded from macro 'deprecated_msg'
218 | #define deprecated_msg(_msg) attribute((deprecated(_msg)))
| ^
ccan/ccan/closefrom/closefrom.c:162:2: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
162 | sprintf(dnam, "/proc/%ld/fd", (long) getpid());
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:278:1: note: 'sprintf' has been explicitly marked deprecated here
278 | deprecated_msg("This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:218:48: note: expanded from macro 'deprecated_msg'
218 | #define deprecated_msg(_msg) attribute((deprecated(_msg)))
| ^
2 errors generated.
make: *** [ccan-closefrom.o] Error 1
```

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Reported-by: Sangbida
Fixes: https://github.com/ElementsProject/lightning/issues/8581
Reported-by: https://github.com/Raimo33
Fixes: https://github.com/ElementsProject/lightning/issues/8501
Changelog-Fixed: build: we now build on MacOS without errors on the latest Command Line Tools (macOS 15 SDK).
Changelog-Fixes: build: fix build with -O2 on 32 bit arm (armhf)

wallet: fix migration speed for postgres.

Testing a large db shows Postgres slowing down exponentially as
it inserts the channel_events. Rather than updating the index in the
db every time, do it at the end, for spectacular speedup:

```
lightningd-1 2025-10-08T05:39:44.333Z INFO lightningd: Creating database
lightningd-1 2025-10-08T05:39:47.581Z DEBUG lightningd: Transferring 6166 chain_events
lightningd-1 2025-10-08T05:39:48.455Z DEBUG lightningd: Transferring 1660043 channel_events
lightningd-1 2025-10-08T05:39:54.390Z INFO lightningd: Inserted 103100/1660043 channel_events
lightningd-1 2025-10-08T05:40:04.390Z INFO lightningd: Inserted 283280/1660043 channel_events
lightningd-1 2025-10-08T05:40:14.390Z INFO lightningd: Inserted 464065/1660043 channel_events
lightningd-1 2025-10-08T05:40:24.390Z INFO lightningd: Inserted 629559/1660043 channel_events
lightningd-1 2025-10-08T05:40:34.390Z INFO lightningd: Inserted 800659/1660043 channel_events
lightningd-1 2025-10-08T05:40:44.390Z INFO lightningd: Inserted 975433/1660043 channel_events
lightningd-1 2025-10-08T05:40:54.390Z INFO lightningd: Inserted 1134719/1660043 channel_events
lightningd-1 2025-10-08T05:41:04.390Z INFO lightningd: Inserted 1290549/1660043 channel_events
lightningd-1 2025-10-08T05:41:14.390Z INFO lightningd: Inserted 1443304/1660043 channel_events
lightningd-1 2025-10-08T05:41:24.390Z INFO lightningd: Inserted 1590013/1660043 channel_events
lightningd-1 2025-10-08T05:41:29.148Z INFO lightningd: bookkeeper migration complete: migrated 6166 chainmoves, 1660043 channelmoves, 132481 descriptions
```

Now we complete the entire migration in 1 minute 45 seconds.

Thanks to @michael1101 for reporting this.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: db: migration from v25.09 on a reasonable size account database could take almost infinite time.

wallet: print progress reports for large account migration.

Show the work we're doing (at debug level) and every 10 seconds print
progress (at INFO level):x

```
lightningd-1 2025-10-08T05:13:07.973Z INFO lightningd: Creating database
lightningd-1 2025-10-08T05:13:10.987Z DEBUG lightningd: Transferring 6166 chain_events
lightningd-1 2025-10-08T05:13:11.780Z DEBUG lightningd: Transferring 1660043 channel_events
```

It's the inserting channel_events which takes a long time, slowing
down exponentially:

```
lightningd-1 2025-10-08T05:13:18.034Z INFO lightningd: Inserted 26690/1660043 channel_events
lightningd-1 2025-10-08T05:13:28.034Z INFO lightningd: Inserted 47086/1660043 channel_events
lightningd-1 2025-10-08T05:13:38.035Z INFO lightningd: Inserted 61699/1660043 channel_events
lightningd-1 2025-10-08T05:13:48.035Z INFO lightningd: Inserted 73743/1660043 channel_events
lightningd-1 2025-10-08T05:13:58.035Z INFO lightningd: Inserted 83244/1660043 channel_events
...
lightningd-1 2025-10-08T05:35:18.286Z INFO lightningd: Inserted 466720/1660043 channel_events
lightningd-1 2025-10-08T05:35:29.074Z INFO lightningd: Inserted 468437/1660043 channel_events
lightningd-1 2025-10-08T05:35:39.079Z INFO lightningd: Inserted 470130/1660043 channel_events
lightningd-1 2025-10-08T05:35:49.081Z INFO lightningd: Inserted 471871/1660043 channel_events
```

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

lightningd: explicit db arg to wait_index_increase so we can use it in migrations.

Before db is complete, ld->wallet->db is NULL.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

pytest: test for malformed reply from first hop when using injectpaymentonion.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

lightningd: handle unparsable onion from first hop when using injectonionmessage.

In this case we have a failmsg, so we should use that. Otherwise we can have
both failmsg and failonion NULL in the call to injectonion_fail, which is not
valid.

```
DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: Removing out HTLC 1 state RCVD_REMOVE_ACK_REVOCATION WIRE_INVALID_ONION_HMAC
**BROKEN** lightningd: FATAL SIGNAL 11 (version v25.09-135-g19a3bbc-modded)
**BROKEN** lightningd: backtrace: common/daemon.c:41 (send_backtrace) 0x6220e8fe0080
**BROKEN** lightningd: backtrace: common/daemon.c:78 (crashdump) 0x6220e8fe00cf
**BROKEN** lightningd: backtrace: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 ((null)) 0x73614bc4532f
**BROKEN** lightningd: backtrace: lightningd/pay.c:1701 (injectonion_fail) 0x6220e8f951c0
**BROKEN** lightningd: backtrace: lightningd/pay.c:330 (tell_waiters_failed) 0x6220e8f943be
**BROKEN** lightningd: backtrace: lightningd/pay.c:656 (payment_failed) 0x6220e8f98db1
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:313 (fail_out_htlc) 0x6220e8fa1d04
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:1988 (remove_htlc_out) 0x6220e8fa271b
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:2086 (update_out_htlc) 0x6220e8fa2904
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:2095 (changed_htlc) 0x6220e8fa2c24
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:2608 (peer_got_revoke) 0x6220e8fa6e5a
**BROKEN** lightningd: backtrace: lightningd/channel_control.c:1555 (channel_msg) 0x6220e8f62725
**BROKEN** lightningd: backtrace: lightningd/subd.c:560 (sd_msg_read) 0x6220e8fb2eed
**BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:60 (next_plan) 0x6220e90a3335
**BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:422 (do_plan) 0x6220e90a3806
**BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:439 (io_ready) 0x6220e90a38c3
**BROKEN** lightningd: backtrace: ccan/ccan/io/poll.c:455 (io_loop) 0x6220e90a524f
**BROKEN** lightningd: backtrace: lightningd/io_loop_with_timers.c:22 (io_loop_with_timers) 0x6220e8f7d1c7
**BROKEN** lightningd: backtrace: lightningd/lightningd.c:1496 (main) 0x6220e8f82db2
**BROKEN** lightningd: backtrace: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main) 0x73614bc2a1c9
**BROKEN** lightningd: backtrace: ../csu/libc-start.c:360 (__libc_start_main_impl) 0x73614bc2a28a
**BROKEN** lightningd: backtrace: (null):0 ((null)) 0x6220e8f53b64
**BROKEN** lightningd: backtrace: (null):0 ((null)) 0xffffffffffffffff
```

Reported-by: @michael1011
Changelog-Fixed: lightningd: potential crash when we receive a malformed onion complain from our first peer when using sendonion / injectpaymentonion.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

bump minimum python to 3.9.2 and downgrade coincurve

This allows compatibility with python 3.14.0 which coincurve 21.0.0 did
not support. The next coincurve release should restore compatibility.

Fixes: #8591

Changelog-changed: pyln-testing requires python>=3.9.2