feat(HT-126): customer-side create endpoint - #201

The server-to-server surface an integrating product uses to create, list,
read, and reply to conversations on behalf of one identified customer.

Defines the three exclusion classes that separate it from the Agent Inbox
contract: internal notes (already required by agent-inbox-v1 §5), unapproved
and discarded drafts (stated here for the first time), and operator workflow
metadata. Each attaches to the /api/v1/customer routing boundary and is
acceptance-tested rather than asserted.

Auth is the deployment service token plus an integrator-asserted customer
email. The trust boundary and its two consequences are stated explicitly.

Adds §6b list, §6c get, and §6d reply, so an integrating product can show a
user their own request history and let them answer in-product rather than
only by mail.

Visibility is one SQL predicate at the query layer, not response filtering:
a thread reaches the customer only if it is not a note, is not an unapproved
or discarded draft, is inbound or actually sent, and — when inbound — comes
from the conversation's own customer. The third condition is the one that
bites: the store persists an outbound row before the network send and
approval writes 'approved' before delivery completes, so draft state alone
would disclose text that never left. The fourth closes forwarded reply
tokens, where routing authority is not disclosure consent.

updatedAt is derived from visible threads rather than passed through. An
internal note bumps the stored column, which would reorder the customer's
list and disclose that unseen activity occurred.

A reply to a spam conversation is refused before appendThread, which reopens
closed OR spam — reaching it would leak the verdict by side-effect.

Migration 034 indexes the normalized customer-email expression. Stored
addresses are verbatim, so the match cannot be plain equality, and an
unindexed expression scans every conversation on every read.

authorKind reports the persisted author kind. Collapsing an assistant to
'agent' would tell a customer a human wrote an AI's reply, which the
charter's actor model forbids; the individual actor id stays hidden.

A list row wants to label its excerpt ("You:" vs the organization) and the
summary carried the text without its author, which would force either a
per-row thread fetch or dropping the label.

Visibility predicate: condition 3 was `inbound OR sent`, which admits an
inbound row carrying any delivery_status — including a combination migration
002's CHECK forbids. The doc comment claimed such a row was hidden; it was
not. Spelled out per direction, with a regression test that drops the CHECK
to seed the row, since the predicate is a whitelist over data this API does
not exclusively write.

Detail read: the summary and thread queries ran as two statements, so a
conversation filed as spam between them still returned 200 with its threads.
Both now share one transaction.

Migration 034 claimed its trailing columns served the list's sort order. They
cannot: the list sorts by a value derived from visible threads, not by
conversations.updated_at. Reduced to the ownership filter it actually
supports, and the gap is recorded rather than papered over.

Spec: attachments are removed from the read surface rather than specified and
unimplemented — serving them means minting bearer-equivalent signed URLs that
must be provably unmintable for an excluded thread. A folded Authorization
header is documented as 401, not 400; reporting 400 would confirm to an
unauthenticated caller that its header parsed.

Create receipt: number and createdAt were re-read after the transaction and
fell back to null and a fresh Date when the read missed, so a client could
persist a fabricated timestamp against a contract with no nullable number.
Both are now returned from inside the creating transaction.

Attachments: the size cap was enforced after each entry was fully decoded,
and verifying a decode allocates a second copy, so one oversized base64
string drove peak memory regardless of the cap. Rejected on encoded length
first.

Acceptance: §8 asserted every criterion was a test. Several were not. Each is
now marked covered or outstanding, and the three that were both cheap and
genuinely missing are written — the snoozed-pending wake, active to active,
and a genuinely duplicated customer header, which a Record cannot express.
The wake branch had no coverage at all.

updatedAt and preview can legitimately come from different threads when the
newest visible one carries no body text; §4b claimed they could not.

Corrects a reference to specs/modules/substrate-v1.md and the module header,
which still described a create-only surface.

… idempotency

Wrapping the two detail statements in a transaction did not close the window
the comment claimed it did. READ COMMITTED gives every statement a fresh
snapshot, so a conversation filed as spam between the summary and the thread
read still returned 200 carrying its threads. The status is now re-checked
after the threads read and the response discarded if it moved, and the
reported status comes from that last observation. A change committing after
the re-check is undetectable by any design and is no longer claimed
otherwise.

§6a specified Idempotency-Key transactional recording and replay semantics
that the endpoint never implements — it does not read the header, so two
identical keyed requests create two conversations. Removed from the contract
rather than left as a promise an integrator could build on.

§4a's formal predicate still read "inbound OR sent" while its prose and the
SQL both require an inbound row to carry no delivery status. The formal
statement is the load-bearing one; it now matches.

Event assertions select by threadId. A conversation carries two
message_received events and claimBatch orders by occurredAt alone, so a
positional pick would tie-break nondeterministically.