feat(chat): scaffold StartChat with a required idempotency key

[bmc08gt]

Draft: blocked on code-payments/flipcash2-client-protocol#14. This branch pins flipcash2-client-protocol 0.8.0, which is not on Maven Central yet, so CI cannot resolve it — expect com.flipcash:flipcash2-client-protocol:0.8.0 FAILED. It goes green once that PR merges and publishes.

What changed upstream

StartChatRequest gained a required idempotency_key (field 9), backed by a new 16-byte IdempotencyKey message. Nothing was removed and nothing was renumbered.

What this does

StartChat had never been scaffolded on Android — no ChatApi, ChatService, repository or controller method existed for it. So this adds the RPC through the full existing Api → Service → Repository → Controller chain, mirroring how joinChat/leaveChat are already wired, with the idempotency key required from the outermost entry point inward.

• IdempotencyKey — a 16-byte @JvmInline value class with a SecureRandom-backed random(), matching BlobId's shape.
• StartChatParameters — sealed interface with the Group variant the proto's parameters oneof currently carries.
• StartChatError — the five Result cases plus Unrecognized/Other.
• Domain→proto mappers for the key and the participation rules.
• ChatController.startChat(parameters, idempotencyKey) takes the key as a required parameter with no default and no internal generation. That is deliberate: the server derives the chat's identity from caller plus key, so a key minted inside the call, fresh per attempt, would satisfy validation while producing exactly the duplicate chats the field exists to prevent. Forcing the caller to supply it keeps minting where the user's intent originates.

The signature covers the new field — setIdempotencyKey is chained before authenticate(owner), which signs buildPartial().

Scope left open

There is no group-chat-creation UI on code/cash to wire this into — NewChatScreen/NewChatViewModel only handle DM-by-handle, and ChatCoordinator.GroupOperations has only join/leave. startChat therefore has no caller above ChatController, so there is no retry path yet in which to reuse a key. The required parameter is what makes a future caller get it right rather than discover the constraint at runtime.

No tests were added for startChat itself. FakeChatRepository in ChatControllerTest gained a stub override, since adding the method to ChatRepository broke the only other implementer.

Builds

Built against the client repo through protoLocalRoot / protoLocalPackages=flipcash2, not a published artifact:

• :services:flipcash:compileDebugKotlin — passes
• :services:flipcash:compileDebugUnitTestKotlin — passes

No wider assembleDebug or :app build was run.