fix: mailing-list addresses in a slice

[mvanhorn]

What?

SearchContacts builds mailing-list virtual contacts by jamming strings.Join(list.Addresses, ", ") into Contact.Email. That breaks the field's single-address invariant: normalizeContactEmail lowercases and trims commas off the joined string (corrupting the data), and any exact-match lookup against the contact will never find it.

This adds a dedicated Addresses []string field to Contact, populates it for mailing-list virtual contacts, and leaves Email empty so the invariant holds. The composer learns to detect mailing lists via len(selected.Addresses) > 0 instead of "does the email field contain a comma", joins the addresses at insertion time, and renders the suggestion as Name (addr1, addr2, ...) so it's clear that a single suggestion expands to multiple recipients.

Files touched:

• config/cache.go -- new Addresses field on Contact; mailing-list construction in SearchContacts switches to it
• tui/composer.go -- detection/insertion and rendering swap from Email commas to Addresses

The cache file format is backwards-compatible: the new field is omitempty, and saved contacts (added via AddContact) never carry Addresses because they're built from a single email parameter. Mailing-list virtual contacts are constructed in-memory on every search and never written to disk.

Why?

Closes #1123. The reporter pointed out the data-integrity bug; this implements option 2 of the two fixes they suggested (dedicated Addresses slice, keep Email empty), which is the smaller of the two and doesn't require a separate "virtual contact" type.

Verification

• go build ./config/... ./tui/...: passes
• go vet ./config/... ./tui/...: passes
• go test ./config/...: 51/51 passing
• go test ./tui/...: 79/79 passing

Disclosure

Authored with Claude as a coding assistant; I reviewed the change before pushing.

[floatpanebot]

Hi @mvanhorn! Please fix the following issues with your PR:

• Title: Is too long (78 characters). The PR title must be strictly under 40 characters.

[floatpanebot]

Hi @mvanhorn! Please fix the following issues with your PR:

• Title: Is too long (78 characters). The PR title must be strictly under 40 characters.

[mvanhorn]

Resolved and pushed a29f108. The conflict was structural -- since this PR opened, master refactored Contact to track usage per-account (Usage map[string]ContactUsage with a legacyContactUsageKey migration path), and that bumped into the new Addresses []string field here.

Merged shape:

type Contact struct {
    Name      string                  `json:"name"`
    Email     string                  `json:"email"`
    Addresses []string                `json:"addresses,omitempty"`
    Usage     map[string]ContactUsage `json:"usage_by_account"`
}

Mailing-list virtual contacts in SearchContacts now leave Email empty, copy addresses into Addresses, and set the 9999 usage score under the active account in the Usage map. The composer's len(selected.Addresses) > 0 check stays as-is and is the canonical way to distinguish mailing-list vs regular contacts.

go build ./..., go vet ./..., and go test ./config/... ./tui/... ./cli/... all clean locally. Branch shows MERGEABLE.

[floatpanebot]

Hi @andrinoff! Please fix the following issues with your PR:

• Title: Is too long (44 characters). The PR title must be strictly under 40 characters.

Formatting issues have been resolved. Thank you!

[andrinoff]

Fix the issue below, and add tests

[andrinoff]

fmt.Sprintf("%s (%s)", s.Name, strings.Join(s.Addresses, ", ")) for a mailing list with many recipients could produce a very long suggestion string and overflow the TUI layout. Let's truncate

[mvanhorn]

Addressed in 14a67a6 — extracted a suggestionDisplay() helper that truncates the mailing-list branch to the composer's available width (width - 6, 40-rune fallback). Truncation is rune-safe and adds an ellipsis. Single-address suggestions are untouched.

Added TestMailingListSuggestionTruncates covering both the truncated mailing-list case and the unchanged single-address case. go build ./... and go test ./tui/... are clean.

[andrinoff]

lgtm