Pro: withhold message features from a revoked sender

[mpretty-cyro]

One behaviour change, one test hook and one comment correction, all in the Pro revocation path. Each commit carries its own reasoning; the summary below is the shape of the set.

The bug

Message features survived a sender's revocation. The revocation list overrides the validity of proofs already in circulation, but libsession's decode cannot see it — the list is cached locally rather than travelling with the message — so a cryptographically valid proof carried its features regardless of whether the sender's generation had been revoked, and a revoked sender kept the higher character limit.

Cleared where the bitset is populated rather than at each consumer, so the bitset is truthful and everything reading it conforms without knowing about revocation: the incoming character limit, the features listed in message info, and what is persisted with the message. The entry's effective timestamp is honoured, as every other read of the list does, so a revocation dated in the future does not withdraw features early.

The badge and avatar are unaffected — they resolve from the contact's stored proof via a separate path that already filters revocations.

Test hook

sessionForceProRevocationRefresh discards the scheduled poll rather than shortening the interval or adding a fetch path, so the ordinary scheduler still decides when to poll and a test exercises that path rather than a parallel one. The backend serves a 24h retry_in, so a client's second poll is a day after its first and no revocation behaviour is otherwise reachable within a test.

Cancelling is the local equivalent of moving a stored next-poll instant into the past: the pending poll here is a WorkManager job carrying a delay, and schedule() enqueues with none, so its KEEP policy would otherwise preserve a job up to 48h from running. The cancel sits immediately before the scheduling it affects rather than where the flag is parsed — reversed, it would cancel the poll it was meant to force.

true or 1 enables and any other value disables, rather than presence enabling, since a key present with a disabling value has to disable. Reachable only where ALLOW_QA_LAUNCH_CONFIG is set, checked both where the flag is written and where it is read.

Comment correction

The expiry-CTA comment claimed "only once per install", which predates clearProExpiryView() resetting the latch when the account reads Active again. The real model is once per Pro cycle, which is the intended behaviour — Pro can only expire once per cycle, so one warning per cycle is the point — and the other clients are being aligned to this model rather than away from it. The stale comment invited a per-launch "fix"; the note records why that was rejected, and that the latch is written on dismissal rather than on display. Comment only, no behaviour change.