[MQTT & Comms] Integrate retry helpers into secure MQTT client factory

[saviornt]

Description

Apply the new general retry utilities (from the retry helpers issue) to the secure MQTT client factory so that connect / subscribe / publish operations become resilient to transient network/MQTT broker issues.

Type

• Epic
• Feature
• Task
• Bug
• Refactor
• Research
• Documentation
• Setup / Tooling

Focus Area (pick one)

• Monorepo & Packaging
• Appliance Core (Pi edge)
• Assistant Core (PC central)
• Shared Utils & Models
• Auth & Security
• MQTT & Comms
• Dashboard & UI
• Observability & Metrics
• Inference & ML
• Testing & CI
• Documentation & Planning

Priority

• Critical
• High
• Medium
• Low

Acceptance Criteria

List the specific, testable outcomes that mean this issue is done.

• create_secure_mqtt_client() or equivalent now wraps connect/subscribe/publish calls with @retry_network or equivalent
• Retries are configurable via shared settings (e.g. mqtt.retry_attempts, mqtt.retry_backoff_min)
• On retry, structured log includes attempt number, delay, and exception type
• Final failure after max retries raises a meaningful custom exception (NetworkChanRetryExhaustedError) with last exception chained
• Unit test(s) simulate broker unavailable → retry → success
• No regression in existing TLS / auth behavior

Blocker / Dependencies

• The general retry helpers issue must be merged first
• [Shared Utils & Models] Implement secure MQTT client factory #5 (secure MQTT client factory already exists)

Notes / Links

• Related files: wherever the MQTT factory lives (likely shared/src/comms/mqtt_factory.py or similar)
• Desired outcome: transient disconnects should not crash components