DMs are atoms with visibility=private + recipient pointer

Substrate doctrine: everything is an atom. DMs are no exception. They were already in the schema (source_kind="direct_message", dm_recipient_user_id); what was missing was the inbox + thread surface.

Why atoms-as-DMs (not a separate dm_messages table):

• A DM is a piece of substrate content. The author can attach intent tags, the assistant can search across them under the read-dms scope, the user can export their DMs alongside their posts via the same data-export path.
• Visibility is enforced by one mechanism (buildVisibilityClause), not two — anti-leak by construction.

What's deliberately not in this ship:

• DM-to-anyone search. v0.5 starts threads via the Message button on a profile page (you must already know who you're DMing). A "compose new DM with user picker" surface is a v0.6+ task; until we ship it, mutual-discovery via profiles is the substrate's "address book."
• Read receipts / typing indicators. Engagement-bait flavored. Not shipping.
• Group DMs. v1+ work. v0.5 is 1:1 only.

The read-dms consent scope (already defined in core/assistant-tools.ts) is exclusive: granting it to the assistant for one query never bundles read-atoms, and vice versa. DMs and atoms are two distinct read paths.