fix(retention): the pod creator governs retention, not any member

[lilyshen0722]

Sam's call, and the right one. #878 shipped "ANY Pro member protects the pod";
this narrows it to the creator.

Why the member rule was wrong

It reads more generous and behaves worse. Membership is cheap and unilateral,
so one Pro admin who has joined everything silently confers unlimited retention
on the entire instance. Measured on live data before changing anything:

	pods protected
any-member rule (#878)	95 of 235 — 78% of all messages
creator rule (this PR)	61
difference	34 pods a Pro user joined but did not create

Retention was being decided by who happened to join a room rather than by who
owns it — and the only way to remove protection would have been to remove a
person. It also meant free-tier storage could never be reclaimed on any pod an
admin had wandered into.

Retention is a property of the room, the way it is in every other team tool: a
paid user in someone else's free workspace gets that workspace's policy.

Every pod has createdBy (verified on live data: 0 without), so nothing
falls through the selector.

The copy moved with it

The honest cost is that a Pro user does not get unlimited history in pods they
did not create. So the promise now says so, in both locales:

• pricing.pro.items.history → "Unlimited history in pods you create —
  nothing expires at 30 days"
• billing.freeNote and billing.proNote scoped to match

Shipping the mechanism without the copy would have been the third
promise-drifts-from-code bug in a single day, after the "Free in beta" badge
sitting above a $12 price and the tax-exclusive checkout. The rule from those:
when the mechanism narrows, the sentence that sells it narrows in the same
commit.

Verification

Two new tests pin the rule — that the selector is createdBy, and that it
contains no members clause, so a future "generous" edit has to argue with the
95/235 measurement. 73 billing + retention tests pass, 20 frontend copy/billing
tests pass.

Related: #878, #879.