test(pro): what happens to Pro-gated state when Pro is revoked, and the CTA handling it needed

[mpretty-cyro]

Description

Four specs covering what happens to Pro-gated state when Pro goes away, plus the harness pieces they
needed. All green on every platform they apply to:

spec	iOS	Android	Desktop
Pins over the standard limit survive Pro being revoked	1.5m	1.3m	18.3s
An animated display picture freezes once Pro is revoked	1.8m	1.0m	1.1m
The home screen shows a Pro badge once the account is Pro	38.0s	31.9s	N/A

What each one claims

Pins survive revocation. The rule is asymmetric and only half of it is enforced anywhere: pins over
the standard limit are kept, and adding another is refused. A client that quietly unpinned the
excess would be destroying user state, and every other pin spec runs at or under the limit where the two
halves are indistinguishable. Both halves are asserted.

An animated picture freezes, for its owner. The neighbouring specs assert this from the far side —
pro_rotation_animated_avatar freezes a recipient's copy, pro_unverifiable_proof_avatar freezes one
whose proof cannot be verified. Neither covers the owner's own device, where the picture is a local file
rather than something fetched, so a client gating only the inbound path satisfies both and still animates
for the one person guaranteed to look at it. The picture being kept is the other half: deleting it
would also stop it animating.

The home badge. Absent for a standard account, present after a grant — asserted in both directions
with the same locator, because "not found" alone is satisfied by a misspelt id or a screen that never
loaded.

The pinned limit across a relaunch is no longer a spec of its own. It is a step on the existing
Pinned conversation limit (non Pro), which already pinned to the limit and asserted the refusal — two
thirds of what a standalone version had to repeat, and it could not shed that half, because the
in-session refusal is the control the relaunch assertion needs. As a step, that control runs immediately
before it.

It is regression cover for session-ios#762: a client that rebuilds its pinned count only when a pin
changes reads zero on a fresh launch and lets a standard user past the limit. iOS carried a count seeded
at zero; Android queries live at the moment of the decision and never had the bug, so the same step now
asserts the behaviour on the platform that was already correct.

That spec's selection is offset by one at the same time. assertPinOrder partitions the before-order into
pinned and unpinned and expects the pinned ones first, so for a prefix selection the expected order is the
before-order itself and the assertion cannot fail. Three order assertions that predate this change were
unfalsifiable until that offset.

Supporting changes

• ctaConfigs.pinnedConversationsRenew — the clients pick the pinned-conversation CTA body from two
  axes (over the limit × previously subscribed), so it is four pieces of copy rather than one. This is
  the over-the-limit-and-previously-subscribed cell; without an entry for it a spec asserting the
  standard copy fails confusingly, and one asserting only "a CTA appeared" passes against the wrong
  dialog. All three clients resolve the same tokens for it.
• HomeHeaderProBadge + the two ids it needs. Scoped rather than reusing the generic
  pro-badge-icon, which the same widget class renders in several roles.
• DesktopWrapper.assertSettingsAvatarNotAnimated — the negative of the existing own-avatar
  assertion. It settles before sampling and requires every sample to match, and it fails on the
  generated placeholder rather than passing, so "the picture was removed" cannot read as "the picture is
  correctly frozen".

The harness changes these specs forced

Three of these were found by the specs above failing in ways that named the wrong thing, so they are here
rather than in a PR of their own.

• dismissCTA takes a mechanism, and confirms the dialog closed. It was a boolean picking between
  two of the three ways out; the third (the "X", the only exit from a CTA with no cancel button) had no
  representation. It now waits on the heading it used to check for presence, so a dismissal is confirmed
  against the same element that defined the CTA as showing. A click returns before the modal finishes
  closing, and the step after it then lands on the overlay and fails naming whatever it was looking
  for — several steps from the cause.
• pinConversation/unpinConversation settle before returning. Every caller was waiting for the
  plus button by hand, and one of them had to tolerate a CTA instead, because a refused pin never
  returns to the list.
• The desktop read status gets its own bound. All three statuses shared 20s, sized for attachment
  uploads. sent and failed are local decisions; read waits on a receipt reaching the recipient and
  travelling back, which on devnet has been seen to take anywhere from ~31s to over 60s.

Also here: ConversationPinnedIcon gains its iOS half, so the pin assertions run on both platforms
rather than Android alone. #165 reached the same locator independently and the merge keeps its version.

Two things worth knowing for review

The gate reads ACCESS, not display status, which is why the revocation specs are shaped as they are.
Access outlives the plan — a lapsed subscriber holding a live proof keeps every Pro feature — so a spec
that only ends the plan is exercising the overhang (pro_overhang), not this. Each of these forces the
revocation to reach the proof and asserts access is gone before asserting the refusal.

forceProRevocationRefresh is a precondition, not a convenience. The backend serves the production
cadence (retry_in: 86400, inside libSession's [60s, 48h] clamp), so without it the client's next
revocation poll is a day away and the proof stays valid for the whole run.

Scope

Each spec covers the revoked case, not the grandfathered one. A user who never subscribed cannot
create either state through the UI — the app enforces the limits they would have to violate — so the
grandfathered variants need the seeder to write conversation priorities and display pictures directly.