MESH-API v0.7.5.3 Beta - Extension Channel-Filter Fix + MeshCore Unified Unit Support

MESH-API v0.7.5.3 Beta - Extension Channel-Filter Fix + MeshCore Unified Unit Support

A focused bug-fix release: closes the last gap in GitHub #59 across the whole
extension ecosystem, and makes MeshCore BLE discovery work with unified
companion+repeater units and current MeshCore firmware.

MeshCore unified companion/repeater units

• Unified units advertise their node name (not MeshCore-*) and may come up
  on a new MAC after a firmware change. meshcore.ble_address now accepts an
  address or a node-name fragment; leave it blank to auto-scan (matches
  MeshCore names or the Nordic UART companion service, ignores Meshtastic
  radios).
• When the configured node isn't seen, the log and WebUI list nearby
  MeshCore-capable devices and explain the one-BLE-client rule: a companion
  node connected to a phone app stops advertising - disconnect the app or
  power-cycle the node.
• On connect, the device model/firmware/role is logged so unified units are
  identifiable at a glance.
• Bundled meshcore Python lib bumped to 2.3.8 (2.2.x predates v1.15
  firmware's binary GROUP_DATA packets).

The bug (#59)

Every bridge/notification extension (Telegram, Discord, Slack, Matrix, Signal,
Mattermost, MQTT, ntfy, Pushover, Apprise, WhatsApp, Zello, generic Webhook,
IMAP) gated ALL of its traffic on inbound_channel_index being set. The
shipped default is null - so with a default config:

• send_all: true silently forwarded nothing to the platform, and
• inbound platform->mesh relay was silently dropped.

Deleting the key (which the WebUI config editor's null-stripping does) produced
the same silent dead state. This is exactly the "Telegram notifications stopped
working" report in #59.

The fix

• inbound_channel_index: null (or absent) now means no filter: every mesh
  channel is forwarded outbound, and platform->mesh messages relay on channel 0.
• Setting an index pins both directions to that one channel - identical to the
  old behavior when configured.
• Extensions no longer re-forward their own relay tag ([TG:...],
  [Slack:...], etc.), so an MQTT/bridge echo can't bounce a message back to
  the platform it came from.
• Discord: inbound webhook + bot polling now route through the shared
  send_to_mesh helper - Discord messages finally honor
  default_send_network and reach MeshCore, not just Meshtastic.
• ntfy: the ntfy->mesh SSE subscription remains opt-in (set an index to
  enable it); only its outbound filter changed.
• All touched extensions bumped to v1.1.0.

Documentation

• EXTENSIONS.md config tables rewritten to match the real config.json
  keys. Several tables documented keys that don't exist (forward_to_mesh,
  broadcast_channel_index, ...) while omitting the ones that do (send_all,
  send_ai, send_emergency, receive_enabled, inbound_channel_index) -
  which is how these misconfigurations happened in the field.

Still a beta - please report anything that breaks on GitHub Issues.