Maker's trade chat shows Unknown instead of the counterparty's nym

[Forte11Cuba]

As a maker, the trade chat header (and the chat list entry) always shows the localized "Unknown" / "Desconocido" instead of the counterparty's deterministic nym, with the default teal avatar. The v1 client (MostroP2P/mobile) correctly shows a handle like `trustless-phoenix` in the same situation.

Root cause

1. Rust: the counterparty pubkey is never persisted for makers

The maker's trade row is created with an empty `counterparty_pubkey` (`create_order`, `rust/src/api/orders.rs`) and nothing ever writes it back. When the daemon's `BuyerTookOrder` / `HoldInvoicePaymentAccepted` message arrives, `on_peer_pubkey_received` derives the ECDH shared key and chat keys and stores the peer pubkey only in the in-memory session the trade row in the DB keeps its empty counterparty forever.

Consequences beyond the cosmetic nym:

• `tradeInfoToChatRoom` (Dart) filters out trades with an empty `counterpartyPubkey`, so the maker's chat room can never resolve the peer identity.
• `resubscribe_active_chats` (`rust/src/api/messages.rs`) filters on a non-empty `counterparty_pubkey`, so a maker who restarts the app silently loses the incoming-chat subscription — the buyer's messages stop arriving until the daemon happens to resend a peer notification.

Takers are unaffected: `take_order` stores the maker's pubkey at take time.

2. Dart: the chat room screen depends on the chat-list tab having run first

`ChatRoomScreen` resolves its room from `chatRoomsNotifierProvider`, but the only code that hydrates that notifier from the trade DB is `ChatRoomsScreen.initState` (the Chat tab). Opening a chat directly trade-detail chat chip, deep link without having visited the Chat tab in that session falls back to a placeholder with an empty handle, which renders as "Unknown" even when the pubkey is available in the DB. Sending/receiving a message then upserts that empty placeholder into the room list, cementing the "Unknown" entry there too.

[Matobi98]

I'd like to take this one.

Planned approach:

1. Rust: persist counterparty_pubkey on the maker's trade row when it's derived in on_peer_pubkey_received (currently only kept in the in-memory session), so it survives app restarts and resubscribe_active_chats keeps the chat subscription alive.

2. Dart: make ChatRoomScreen watch chatRoomsFromTradesProvider (the same provider that hydrates the Chat tab) instead of reading only from chatRoomsNotifierProvider, so opening chat from the trade detail resolves the room on its own instead of depending on the Chat tab having run first — no more falling back to the empty "Unknown" placeholder.

Will open a PR once both are implemented and manually verified against a local mostrod/regtest setup.

[Forte11Cuba]

I'd like to take this one.

Planned approach:

1. Rust: persist counterparty_pubkey on the maker's trade row when it's derived in on_peer_pubkey_received (currently only kept in the in-memory session), so it survives app restarts and resubscribe_active_chats keeps the chat subscription alive.

2. Dart: make ChatRoomScreen watch chatRoomsFromTradesProvider (the same provider that hydrates the Chat tab) instead of reading only from chatRoomsNotifierProvider, so opening chat from the trade detail resolves the room on its own instead of depending on the Chat tab having run first — no more falling back to the empty "Unknown" placeholder.

Will open a PR once both are implemented and manually verified against a local mostrod/regtest setup.

Hi @Matobi98 thanks but this issue is already addressed in PR #347

[Matobi98]

Ah, missed that, thanks for the heads up! Will pick up something else.