
## Summary of All Changes (nuntium only)

All fixes are in the **nuntium** package. No changes were needed in telepathy-ofono, lomiri-history-service, or lomiri-messaging-app — the downstream routing logic in telepathy-ofono was already correct; it just wasn't receiving the right data from nuntium.

### Bug 1 (Primary): Group MMS messages routed to 1:1 threads

**Root cause**: The `Cc` field in [MRetrieveConf](cci:2://file:///home/jmacdonald/Projects/UT/nuntium/mms/mms.go:251:0-267:1) was declared as a `string` instead of `[]string`. The MMS decoder would overwrite it with each CC entry (only keeping the last one), and [parseMessage](cci:1://file:///home/jmacdonald/Projects/UT/nuntium/telepathy/service.go:479:0-534:1) never included CC recipients in the `Recipients` D-Bus signal at all. So telepathy-ofono only saw the `To` field (which was just the UT device's own number), making every group MMS look like a 1:1 message.

**4 files changed, 3 logical fixes:**

1. **[mms/mms.go](cci:7://file:///home/jmacdonald/Projects/UT/nuntium/mms/mms.go:0:0-0:0)** — Changed `Cc` from `string` to `[]string` in [MRetrieveConf](cci:2://file:///home/jmacdonald/Projects/UT/nuntium/mms/mms.go:251:0-267:1)
2. **[mms/decoder.go](cci:7://file:///home/jmacdonald/Projects/UT/nuntium/mms/decoder.go:0:0-0:0)** — Added [ReadCc()](cci:1://file:///home/jmacdonald/Projects/UT/nuntium/mms/decoder.go:200:0-209:1) method (mirrors [ReadTo()](cci:1://file:///home/jmacdonald/Projects/UT/nuntium/mms/decoder.go:187:0-198:1)) that appends to the `[]string` slice; updated the decoder switch to use it
3. **[telepathy/service.go](cci:7://file:///home/jmacdonald/Projects/UT/nuntium/telepathy/service.go:0:0-0:0)** — Combined `To` + `Cc` into `allRecipients` before emitting the `Recipients` D-Bus property

### Bug 2: Initial download fails with "Couldn't resolve host name"

**Root cause**: After [toggleActive(true)](cci:1://file:///home/jmacdonald/Projects/UT/nuntium/ofono/modem.go:338:0-362:1) returns, the PDP context may not have its network interface fully ready yet. The download fires immediately and DNS resolution fails because the bearer isn't up.

**Fix in [ofono/modem.go](cci:7://file:///home/jmacdonald/Projects/UT/nuntium/ofono/modem.go:0:0-0:0):**

4. Added [waitForContextReady()](cci:1://file:///home/jmacdonald/Projects/UT/nuntium/ofono/modem.go:320:0-336:1) — polls `Settings.Interface` every 500ms (up to 10s timeout) after activation
5. Called it from [ActivateMMSContext()](cci:1://file:///home/jmacdonald/Projects/UT/nuntium/ofono/modem.go:262:0-287:1) after [toggleActive](cci:1://file:///home/jmacdonald/Projects/UT/nuntium/ofono/modem.go:338:0-362:1) succeeds

### Bonus fix: Inverted log condition

6. **[ofono/modem.go](cci:7://file:///home/jmacdonald/Projects/UT/nuntium/ofono/modem.go:0:0-0:0)** [getContextProperties()](cci:1://file:///home/jmacdonald/Projects/UT/nuntium/ofono/modem.go:313:0-318:1) — Fixed `err == nil` → `err != nil`. Was logging "Cannot get properties" on **success** and silently swallowing real errors.

---

**Note**: The pre-existing build failure in [mms/download.go](cci:7://file:///home/jmacdonald/Projects/UT/nuntium/mms/download.go:0:0-0:0) (`CreateMmsDownloadWithContext` / `CreateMmsUploadWithContext` undefined) is unrelated to these changes — it's a go-ldm API mismatch that presumably gets resolved at package build time with the correct [go-ldm](cci:9://file:///home/jmacdonald/Projects/UT/go-ldm:0:0-0:0) version.