Browser persistence lastId should not rely on timestamp

[singpolyma]

timestamp is the time the message was sent (that is, it takes into account delay tags). So getting lastId by this means that sometimes we get a non-last id and thus end up fetching messages we already have. That's not fatal, but in a Channel it means we end up with the wrong unread count because the Channel sync code assumes any messages it gets from the sync are new and thus unread.

We could solve this by re-querying the store to get the unread count after sync. This might be safer due to race conditions of live messages arriving during sync operations. (Unless we switch to a sync-first approach, but that has race conditions that can lead to lost messages...)

OTOH lastId being based on timestamp is clearly wrong. It probably shouldn't be based on any timestamps at all, but since we aren't promised MAM ids are sortable we get into the thorny issue of producing our own sortable ids locally which is possible but we have not done yet.