### Summary
- Added a new method `get_channels_with_hash()` to the `Node` class.
- This method returns a list of dictionaries, each containing the channel index, role, name, and a hash value derived from the channel name and PSK.
- The hash is calculated using the existing `generate_hash` utility, ensuring consistency with other parts of the codebase.
- This utility makes it easier to programmatically access channel metadata, including a unique hash, for scripting, debugging, or integration purposes.
### Motivation
- The protobuf `Channel` objects do not include a hash value by default.
- This addition provides a Pythonic, easy-to-use way to access channel info and a unique hash for each channel, which can be useful for diagnostics, scripting, or UI display.
### Example Usage
```python
channels = node.get_channels_with_hash()
for ch in channels:
print(f"Index {ch['index']}: {ch['role']} name='{ch['name']}' hash={ch['hash']}")
```
### Impact
- No breaking changes; existing APIs and CLI output remain unchanged.
- The new method is additive and can be used where needed for enhanced channel introspection.
Some time ago I updated the protocol so that after sending NODEINFOs to
client devices (via fromRadio protobufs), it would proactively send the
channel definitions. Prior to this the client had to ask for each channel
by sending an admin request. This handshaking was really slow for mobile/
bluetooth clients. So in the current device code (last couple of years)
the device automatically sends this info to the client during initial config
download.
Unfortunately I never updated the python client to expect this. I assumed
(incorrectly) that it would just cope and keep sending the channel requests
the old way it always had (which is still supported by devices - and
required for remote administration of nodes).
This change removes sending channel requests (for the local node only)
from the python startup code. It also now understands (no longer ignoring)
the channels which were sent proactively by the local device.
This makes connection/config/api operations from the python client 100%
reliable again. Previously it would only work sometimes depending on how
quickly it was able to get the local node db downloaded.
Also this flow is much faster - which should help all users of the python
api.
Changes to make --info much more human readable (while still keeping
machine readabilty for anyone foolish enough to be parsing the existing
output as text)
* change message_to_json to optionally not strip the multiline JSON
* use multiline=True for the two places we are printing to the console
* make the node list JSON indented