[geonnave]

mari-edge connects to the broker from the serial reader thread, on the first GATEWAY_INFO. When the TLS handshake fails, for example against a broker whose certificate has expired, the exception killed that thread: the gateway was never read again while the display kept running as if nothing was wrong. There was also no way to skip certificate verification for a bench session.

Now:

• A failed connect is printed with its reason and paho keeps retrying in the background; the serial thread survives. A certificate failure adds a hint pointing at MARI_MQTT_INSECURE=1.
• MARI_MQTT_INSECURE=1 (1/true/yes/on) makes the TLS context skip certificate and hostname verification, with a warning. Otherwise marilib passes paho's verifying default, unchanged.
• A broker that refuses the connection (bad or missing credentials) is reported with its reason and a hint naming MARI_MQTT_USER / MARI_MQTT_PASS, instead of a subscribe printed as if it had worked.
• mari-edge, mari-cloud and examples/mari_edge_stats.py share one mqtt_options_from_env() instead of three copies of the credentials helper.

Breaking: the credentials are read from MARI_MQTT_USER / MARI_MQTT_PASS instead of DOTBOT_MQTT_USER / DOTBOT_MQTT_PASS, so marilib stops depending on another project's variable names. Programs that pass username / password to MQTTAdapter.from_url explicitly are unaffected; anyone running mari-edge or mari-cloud by hand against an authenticated broker must export the new names.

Validation: marilib suite passes (75 tests, 15 new cases for the env parsing, the TLS contexts and an unreachable broker not raising, and a refused CONNACK); ruff check clean. Live against a broker with an expired certificate: without the variable the reason and hint are printed and nothing raises; with MARI_MQTT_INSECURE=1 it connects and subscribes. Not yet run with a gateway attached.