lnworker: keep watchtower sync alive on invalid get_ctn replies

[rdymac]

Summary

• Validate get_ctn from a remote watchtower (must be a non-negative int) before feeding it to range() / assert ctn >= 0.
• Catch per-channel and unexpected errors inside the while True sync loop so one bad reply cannot kill watchtower updates for the rest of the session.

A JSON-RPC get_ctn result was used unvalidated. A negative or non-int value (including HTTP non-200 returning an 'Error: …' string) escaped the loop's except aiohttp.ClientError. The coroutine is spawned once in start_network, so syncing then stopped for all channels until restart.

Tests

Optional tests live on a separate branch, not in this PR: watchtower_invalid_ctn-test. Pull that if you want the unit tests as well.

Comments already received on the suggested fix

util.py:763 already has is_non_negative_integer, and lnworker.py:38 already imports from .util.

is_non_negative_integer(True)  -> True     # bool subclasses int

is_integer is just isinstance(val, int), so the helper accepts True/False. type(watchtower_ctn) is not int rejects them. A watchtower answering JSON true would otherwise become range(2, n) silently treated as ctn=1.

Suggested in-code comment:
python

# note: `type(x) is int` rather than isinstance/is_non_negative_integer:
#       bool subclasses int, and a JSON `true` would otherwise be read as ctn=1
if type(watchtower_ctn) is not int or watchtower_ctn < 0: