fix(self-hosted): real conversations, honest source scopes, and a --read filter that pages

[andrei-hasna]

What was wrong

Five read-path projections in the self_hosted MailDataSource returned a confident wrong answer instead of the truth or an error. Each one is shaped so an operator cannot distinguish it from a legitimately empty result.

#	Symptom in self_hosted	Was
1	emails email replies <sent-id> prints No replies. / {"replies":[],"total":0,"has_more":false} for a sent message that did get replies; email thread / conversation always render (1 message)	getConversation() / getConversationBodies() returned [the message itself]
2	thread_id permanently null everywhere, including emails reply's output	v1ToTuiMessage hardcoded thread_id/provider_thread_id to null
3	inbox list --source <id> prints No mail found; inbox mailboxes --source <id> prints all-zero folder counts — over a full store	any scope without an address/domain narrowed to nothing
4	inbox sources --search x --limit n returns the unfiltered list	listMailboxSources(_opts) ignored both
5	inbox list --limit 20 --read can return fewer than 20 rows while more matching rows sit on the next page	--read post-filtered an already-paged response

Item 3 was a self-inflicted trap: listMailboxSources() fabricates a source with id self_hosted, and inbox.remote.ts tells the operator to pass exactly that id from emails inbox sources. Doing so returned an empty mailbox.

What changed

Conversations are real. The self-hosted store has no thread_id column; its one server-side notion of a conversation is the normalized (Re:/Fwd:-stripped, lower-cased) subject that GET /v1/messages/threads groups by (store.listThreads). threadKeyOfSubject() mirrors that SQL expression-for-expression, and conversationRows() groups by it plus the RFC 5322 Message-ID/In-Reply-To links every row carries, so a reply survives a rewritten subject. Candidates are narrowed server-side with ?subject=, so one conversation read costs one or two requests — not the full-store scan the label/oldest paths pay. A message with an empty subject has no conversation key and stands alone: collapsing every empty-subject message into one thread would be a fabrication, not a thread.

thread_id is the server's conversation key, derived from the subject the row already carries — no extra round-trip, present on list rows and detail reads alike. provider_thread_id stays null because the store genuinely has no such column.

Source scopes are honest. self_hosted (and local mode's all) resolve to the whole store, so the id emails inbox sources prints round-trips into --source. A scope the /v1 store cannot express — provider, S3 bucket, legacy, unknown id — is refused with a message naming what is supported, instead of silently reporting an empty mailbox. clear() resolves the scope before scanning, so it can neither delete nothing while reporting success nor widen to the whole store.

--read is part of the query (MailboxListOptions.read), applied inside the paging walk so a page fills.

Every user-facing string touched here was re-verified:

• thread headers show the whole conversation key (Thread "declaratii tva 06.2026" (3 of 3 messages)) instead of Thread declarat, an 8-char slice of a subject that named nothing;
• an empty page of a non-empty thread no longer claims the thread is empty;
• replies is now described as what it returns;
• --provider / --source help text says what self_hosted actually supports;
• the empty-mailbox hint no longer suggests emails refresh — that command is not registered in any mode.

--limit/--offset on email thread / conversation were accepted and ignored; they now page the thread and the payload reports total / has_more.

Deliberate semantic note

replies returns the whole inbound side of the conversation, not local mode's strict depth-1 in_reply_to_email_id children (the /v1 rows expose the conversation, not a parent-child edge per message). The response shape is identical to local's ({ replies, total, limit, offset, has_more }), and under-reporting a reply is precisely the failure this replaces.

Tests

New tests fail before this change and pass after — 22 of them, verified by stashing the source changes and re-running:

• src/lib/self-hosted-mail-data-source.test.ts — 10 fail before / 0 after (conversation, multi-hop reference chain, empty-subject non-grouping, thread key on list rows, body windowing, source round-trip, all alias, refusal for provider/S3/legacy/unknown, clear refusal, sources --search/--limit, --read paging)
• src/cli/commands/email-log.test.ts + src/cli/commands/inbox.test.ts — 12 fail before / 0 after, driving the real commands against the out-of-process /v1 stub

Two stale test titles that encoded the bug were corrected, and reply.test.ts's expect(data.thread_id).toBeNull() now asserts the real conversation key.

bun test          2068 pass, 85 skip, 0 fail   (baseline on origin/main: 2044 pass, 0 fail)
bunx tsc --noEmit exit 0
bun run build     ok

Also re-run under CI's environment (HOME=<tmp> EMAILS_MODE=local EMAILS_DB_PATH=:memory:): 2068 pass, 0 fail.

Rebase note

Branched from origin/main @ 1ac2d15 (verified via gh api). PR #53 is still open and also edits src/lib/self-hosted-mail-data-source.ts and src/cli/commands/email-log.remote.ts. Its hunks are the status/send_state ones, but two will collide textually: v1ToTuiMessage (it adds fields next to the thread_id/provider_thread_id lines this PR rewrites) and mail-types.ts TuiMessage vs this PR's MailboxListOptions. Rebase this branch after #53 lands. Do not merge before then.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}