Subscriber status refactor

[magush27]

The subscriber.status and transaction.subscriptionState were two separate, inconsistently-written sources of truth for a user's subscription status. Android normalized status inside a hidden Mongoose post('validate') hook on the model; iOS and PayPal each did their own ad-hoc normalization directly in the controller, with PayPal in particular leaving some raw values (like ACTIVE, APPROVAL_PENDING) unnormalized.

This PR makes getSubscriber the single place that derives subscriber.status, using a shared normalization helper across all three platforms.

• Add api/helpers/subscriptionStatus.js: normalizeSubscriptionStatus() maps raw platform states (including Android's SUBSCRIPTION_STATE_* constants) into Cboard's internal status vocabulary, falling back to not_subscribed for anything unrecognized. PAYPAL_STATUS_MAP maps PayPal's raw subscription statuses (including approval_pending/approved → proccesing, previously left as raw uppercase strings).
• Remove the post('validate') hook from api/models/Subscribers.js — the model layer no longer derives business status, only validates shape.
• api/controllers/subscriber.js: Android, iOS, and PayPal branches of getSubscriber now all route through the shared helper. The Android branch normalizes after save() resolves and only issues a second save() when the computed status actually changes.

Test plan

• npm test — full suite passes (150 passing; the 1 pre-existing failure in Access API calls is unrelated to this change)
• Manual check against a local dev db with mocked Google Play responses for active, expired, and in_grace_period states
• Verified the Android branch's conditional second save() does not trigger a duplicate Google Play API call