fix: the membership status vocabulary moves beside Membership, so the Patreon client never imports the roster

240f11c made PatreonClient._membership import has_paid_access from membership_roster. test_gated_reason::test_no_fetch_path_can_read_the_roster failed on it, correctly: native_ingest_common is a fetch root, patreon_client is reachable from it, and no fetch path may be able to reach the roster. The roster is allowed to explain a skip, never to cause one.

MEMBERSHIP_STATUS and has_paid_access are pure platform knowledge with no database behind them. They move to native_ingest_common, next to the Membership type they interpret (the same move C7 made for Membership itself). membership_roster, membership_reconcile, patreon_client and the tests import them from there. There is no re-export from membership_roster.

The guard is unchanged. The lapsed-orphan skip from 240f11c stays as it was.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SHQB1YukL3VyvMK8rcbmV9

backend/app/services/native_ingest_common.py

@@ -231,7 +231,7 @@ class Membership:
 
     `status` carries the PLATFORM's own word, verbatim and unmapped
     (`active_patron`, `former_patron`, ...). Deciding what it means is the read
-    site's job — `membership_roster.has_paid_access` — precisely so an
+    site's job — `has_paid_access`, below — precisely so an
     unrecognised word records as evidence rather than as a decision.
 
     `is_free_member` is SEPARATE from status and must stay that way. Patreon
@@ -396,3 +396,81 @@ class BaseNativeDownloader:
         sidecar_path = media_path.with_suffix(".json")
         sidecar_path.write_text(json.dumps(data, indent=2))
         return sidecar_path
+
+# --- membership status vocabulary (#387) ------------------------------------
+#
+# Lives here, beside `Membership`, rather than in `membership_roster`. It is
+# pure platform knowledge with no database behind it, and the platform clients
+# need it too. Patreon's must tell a lapsed membership to a deleted creator
+# (skippable) from a paid one it cannot attribute (drift), and a client may not
+# import `membership_roster`: test_gated_reason.py forbids any fetch path from
+# reaching the roster, so the roster can explain a skip but never cause one.
+#
+# Platform word -> whether the account currently has paid access.
+#
+# Every entry here must come from a CHARACTERISED response, never from API docs
+# or a plausible guess — project rule 130, and inventing a status before seeing
+# it in a real payload is exactly the failure it names.
+#
+# patreon: from a live capture of the operator's own session, 2026-09-10
+# (Scribe note #3886). Only two values were OBSERVED in `patron_status` and
+# only those two are here.
+#
+# `declined_patron` is deliberately ABSENT even though it looks obviously
+# right. It appears in the request's `filter[membership_type]`, and the capture
+# proved that filter is NOT the same vocabulary as the attribute — a row
+# selected by the filter as `free_member` came back with
+# `patron_status: former_patron`, a word the filter does not contain. Reading
+# the filter as an enum is the specific mistake the capture caught; adding
+# `declined_patron` on the strength of it would be repeating that mistake one
+# step later.
+#
+# Unknown words are NOT an error: an unrecognised status means the roster
+# records evidence it cannot yet interpret, which is a better state than
+# dropping the row or asserting a meaning for it.
+#
+# subscribestar: from a live capture of the account's /subscriptions page,
+# 2026-09-13 (Scribe note #3989). SubscribeStar gives NO per-row status word —
+# a membership's state is which of two tables it sits in — so the "word" stored
+# is the table card's own `data-identifier`, verbatim. Those two identifiers are
+# the whole vocabulary; there is nothing further to characterise later.
+MEMBERSHIP_STATUS: dict[str, dict[str, bool]] = {
+    "patreon": {
+        "active_patron": True,
+        "former_patron": False,
+    },
+    "subscribestar": {
+        "active_subscriptions": True,
+        "cancelled_subscriptions": False,
+    },
+}
+
+
+def has_paid_access(
+    platform: str, status: str | None, *, is_free_member: bool = False,
+) -> bool | None:
+    """Does this membership mean the account currently PAYS for access?
+
+    Returns None for a status this code has not been taught, which callers must
+    treat as "unknown" rather than as False. The difference matters: False says
+    the operator has lost access, and asserting that from an unrecognised word
+    would tell them to cancel a source they are still paying for.
+
+    `is_free_member` is a second axis, not a status, and that is Patreon's
+    design rather than ours: the capture shows a free follow expressed as a
+    boolean alongside `patron_status`, so a "current" membership can still be
+    one nobody is paying for. Taking status alone would report a free follower
+    as a paying patron, and C4 would then never offer to clean it up.
+
+    (Honest limit: the capture contains no ACTIVE free member, so it cannot
+    demonstrate the two axes coming apart. The separation is what the payload's
+    shape says; the sample only shows it is possible, not that it happens.)
+    """
+    if status is None:
+        return None
+    known = MEMBERSHIP_STATUS.get(platform, {}).get(status)
+    if known is None:
+        return None
+    if not known:
+        return False
+    return not is_free_member