feat(inbox): expose trackingIds on InboxMessage

[mikemilla]

Ticket: C-19804

Flutter apps could not track inbox clicks at all

InboxMessage had no trackingIds field, so fromJson dropped the key. Meanwhile CourierClient.inbox.click requires a trackingId:

Future click({required String messageId, required String trackingId}) async

…with no way to obtain one from the message. So click tracking was effectively unreachable from Dart.

The data was already arriving

Both platform handlers serialize a message with the native SDK's toJson(), and both native InboxMessage types encode trackingIds. The key has always been present in the payload crossing the platform channel — this model just never read it.

That's why this part was never blocked, unlike the rest of C-19804: no protocol version, no native SDK release, nothing to wait on.

Change

• InboxMessageTrackingIds covering all seven ids the server publishes: archive, channel, click, deliver, open, read, unread
• read in fromJson, written in toJson
• clickTrackingId convenience accessor for the id click() needs
• parsing is defensive — the field arrives untyped over a platform channel, so a non-object value yields null rather than throwing

Read from the root of the message, which is where both the GraphQL read and the iwpv=v2 socket publish it. Nothing here depends on the protocol version.

Tests

First test directory in this package. flutter test 7/7, flutter analyze clean:

• all seven ids parsed; clickTrackingId accessor
• absent, partial, and non-object trackingIds inputs
• toJson round-trip survives a second parse
• other fields unaffected

🤖 Generated with Claude Code

[linear]

C-19804

[mikemilla]

Parking this PR during a PR-cleanup pass. The branch is kept (not deleted) and the work is tracked in C-19804 (cycle 367). Reopening restores everything — branch, commits, and this thread.