feat(payments): send an explicit action on every tip DM payment

[bmc08gt]

flipcash2-client-protocol 0.5.0 adds action to
intent.v1.ChatMetadata.TipDmPayment. This pins 0.5.0 and sets the field. The
iOS side is code-payments/code-ios-app#752.

Who decides the verb

The recipient's "You tipped" / "You sent" comes from messaging.v1.CashContent.verb,
which the server writes. Neither client ever sets it — iOS reads it once, at
ConversationMessage.swift:163-169; Android reads it at ProtobufToLocal.kt:159-170,
and the one setVerb it has (LocalToProtobuf.kt:127-141) is unreachable because
nothing builds outbound CashContent.

Server side that resolution is intent.GetDmPaymentVerb (flipcash2-server,
intent/chat.go:117-138). It prefers action, and falls back to location only when
action is DEFAULT. location has exactly one reader in the whole server — that
fallback. action has exactly one reader — the switch above it.

The resolved verb drives three things, which is why it is worth getting right:

• the cash message injected into the DM (task/chat.go:89),
• the sender's activity feed title (activity/localization.go:30),
• and the tip DM validation rules (intent/chat.go:258).

action is not optional here

Validation keys off the same verb (validateTipDmAppMetadata, intent/chat.go:252-308):
a tip may target a chat that does not exist yet and must clear the per-currency
minimum plus the recipient's initialization fee; a send has no minimum but is denied
with "tip dm has not been initialized" unless the chat is already there.

So the payment that opens a tip DM must resolve to TIPPED. Sending action = SEND
on that path would be rejected outright. This is the constraint both clients had
already discovered from the outside and recorded imprecisely as a rule about
location (SendAmountViewModel.swift:86-95, ChatViewModel.kt:1073).

What each app sends

Situation	location	action
Payment from a scanned or linked tip card	TIPCARD	TIP
The payment that opens the tip DM	TIPCARD	TIP
Send Cash inside an initialized tip DM	CHAT	SEND
Contact (phone) DM payment	n/a	n/a

Same rule on both platforms. ContactDmPayment has no action field.

DEFAULT is never sent

Each app models the action locally with two values, so DEFAULT is unrepresentable
rather than merely avoided. Location's zero value is TIPCARD, not an unknown, so a
message that leaves action unset is indistinguishable on the wire from one
deliberately declaring a tip — the server's own comment at intent/chat.go:130-133
spells that out. Leaving the field at DEFAULT hands the verb back to the inference
this field exists to replace.

location does not move

Not one location byte changes on any path, and that is deliberate: it is the
compatibility path. Server support for action landed on 2026-09-09
(flipcash2-server#196), one day before flipcash2-client-protocol 0.5.0 was cut. A
server without that commit reads location alone.

Because action is set to exactly the verb location already implied, both server
versions resolve the same verb, so these clients are correct against either. Make
location honest at the same time — send CHAT for a chat-composed payment that
opens the DM — and the two versions disagree: the new one allows it, the old one
denies it as an uninitialized send. That cleanup is worth doing once #196 is
confirmed deployed everywhere, and it is a one-line change on each platform then.

On Android specifically

TipAction sits next to TipOrigin in DmPaymentMetadata.kt and
buildTipDmPaymentMetadata now requires it, so no call site can forget it.
TipPaymentDelegate.send takes it through. TippingCoordinator passes TIP —
a tip card has no send path.

ChatViewModel computed isTip and used it for two things that had drifted
apart in wording: picking the location and picking the analytics event. It now
computes one tipAction and all three read off it — the wire field, the
location, and the event.

Not fixed here

The "Swipe to Tip" label and the tip fee floor come from
openingTipRecipientFlow, which decides tip-ness from isChatInitialized —
chat members observed from the server — rather than from typingConstraints
like the send handler and the button label do. Those two read the same
expression on the same state and cannot disagree with each other; this one can
disagree with both, because it depends on a server round trip they don't wait
for. So the swipe label can promise a tip while the payment declares a send.

This change puts the wire field on the send handler's side rather than adding a
fourth predicate, but the split is still there.