perf(mobile): keep verified-name batches open as people are added - #9450

Verified names are read in subscriptions of up to 128 people. Each time someone new was tracked, the batches were rebuilt from the whole tracked list, so the last partial batch got a new identity, was closed, and was reopened with everyone in it plus the newcomer. Profiles show up a few at a time (search results, channel members, mentions), so the same records were read again and again. Past 1,024 tracked people, each newcomer evicts the oldest, which shifts every batch boundary, so every batch was closed and all 1,024 records were read again.

Now an open batch stays open as long as all its people are still tracked. Newly tracked people get a batch of their own. A batch that loses someone to eviction, or that the relay retried, is replaced as before, and so is a batch whose person was evicted and tracked again before the batch was re-checked, so their check mark and cached name are re-read. Once four batches are smaller than 128, the next addition merges the smallest of them with the newcomers until they fill a batch (at least one, so no fifth small batch appears). The subscription count stays within four of the minimum, and a merge re-reads at most 128 plus the largest small batch.

People already checked also stay checked while a newcomer's batch opens; before, the reopened batch briefly unchecked them.

Validation

New tests: tracking one more person opens a batch with only that person, and the people already checked stay checked throughout; with four small batches of 64 open, one more person merges two of them into a full batch and leaves the other two open; a large addition past four small batches still retires one; tracking one more person at the 1,024 limit re-reads only the batch that lost the oldest person; a person evicted and tracked again before the sync is re-read and checked; and a re-tracked person keeps their verified name when the cached-name limit trims it. Existing batch, eviction, retry and reconnect tests pass unchanged (one comment updated). Full mobile test suite and flutter analyze pass.

On an iPhone 12 mini signed in to Block's Builderlab (instrumented profile build of e2fb02c), opening search and typing "presence" after opening a channel and a thread: verified-name reads went from 21 subscriptions and 328 KB before this change to 11 and 88 KB with it (counted per subscription opened; the first revision measured the same way gave 11 and 90 KB).

The same automated run covered cold start, opening the-squad and one of its threads, search with the People filter, opening buzz-mobile's details and scrolling its full 86-person member list, and a 60 s background then resume (the resync re-read 2 batches, 65 KB). Names rendered throughout.

Regressions

Up to four more open subscriptions while small batches accumulate, each held open by the relay like the existing ones. A community with under 128 tracked people now has up to five instead of one. No merge policy reads less than the old slicing on every sequence of additions. In a model of 3,000 random tracking sequences, this one read more records than the old code in about 1 sequence in 500, by at most a quarter.