Define failure semantics for v2 conversation start

[chughtapan]

Problem

The production implementation in PR #974 composes HarnessClient.startConversation from two separate operations:

1. create and announce a conversation;
2. send the required initial content.

If the second operation fails after the first commits, the public call returns only an error and loses the committed conversation identifier. A caller retry can create a second conversation.

The accepted production contract makes no atomicity or recovery promise for this v1 path. Do not expand the retiring v1 implementation to solve it.

Required v2 decision

Before freezing the final v2 interface, make conversation start unambiguous under retries and partial failure. Choose and specify one of:

• one atomic/idempotent start operation with a stable result; or
• a typed partial-commit result that returns the committed conversation and defines how initial-content delivery resumes.

The public interface must not collapse "nothing committed" and "conversation committed, initial content uncertain" into the same untyped error.

Cutover handling

This does not block landing PR #974. Treat it as an input to the four-layer v2 interface and endpoint-owned history/reconciliation design.

Acceptance

• The normative v2 spec defines the commit point and retry identity.
• A lost response or initial-content failure has a deterministic recovery path.
• Tests cover retry after the conversation commit and before initial-content confirmation.
• Reconciliation uses endpoint-owned history; it does not require a central Ledger layer.