Add MQTT config subscription and callback handling

[TalkingJupiter]

Context

RuntimeConfig parsing exists, but the firmware does not yet subscribe to any MQTT config topic or apply received config.

Scope

Subscribe to a per-device config topic and parse config messages.

Suggested topic:

repacss/devices/<mac>/config

Implementation notes

• Add mqttClient.setCallback(...) in TelemetrySender.cpp.
• Subscribe after successful MQTT connect.
• Convert the callback payload into a String or bounded buffer safely.
• Pass config JSON into parseRuntimeConfigJson(...).
• Store accepted config somewhere the main firmware can use.

Acceptance criteria

• Firmware subscribes to the config topic after MQTT connect/reconnect.
• Retained config messages are received after reconnect.
• Valid config JSON is parsed into RuntimeConfig.
• Invalid config JSON is rejected with a useful serial log message.
• Telemetry publishing continues even if config is invalid or missing.

[TalkingJupiter]

Config receive path is in on feature/mqtt_hello (a06b52d) — ended up in the same commit as the hello work since the two grew dependent on each other.

Going through the acceptance criteria:

• Subscribe after connect/reconnect — done. connectMqtt() subscribes to repacss/devices/<mac>/config right after a successful connect, and since every reconnect runs through that same path it re-subscribes on its own. No subscription state to babysit.
• Retained config after reconnect — comes for free from the above; anything retained shows up the moment we resubscribe.
• Valid JSON parsed into RuntimeConfig — payload gets copied out of the PubSubClient buffer (using the length, since it isn't null-terminated), handed to parseRuntimeConfigJson(), and the result is stored on the sender via setConfig().
• Invalid JSON rejected with a log — bad payloads are dropped with [CONFIG] Rejected: <reason> on serial, and the reason bubbles up from the parser so it actually tells you what was wrong.

So 4 of the 5 are solid.

The last one — "telemetry publishing continues even if config is invalid or missing" — isn't true anymore, and that's on purpose. After the topic-ownership call in #7 we went with the config-required model, so with no valid config the device stays quiet instead of publishing. That criterion was written before we made that decision, so it's really a leftover assumption rather than a regression.

If we're good with the Model 3 direction (I am), then this is basically done and I'll close it. Just want to give it a proper look first, so leaving it open for now.