Ask @workspace where something is actually handled before you change it

@workspace I am about to change how a user's subscription tier is determined for feature gating, and I want a map of everywhere it
actually lives in this codebase before I touch anything — answer using what you can actually find
in this workspace, not general knowledge of how a feature like this is usually structured.

QUESTION 1 — WHERE IS IT
Every file that reads, writes, or otherwise depends on how a user's subscription tier is determined for feature gating, and for each one
the specific function, component, or export involved — not just the filename.

QUESTION 2 — WHICH ONE IS THE SOURCE OF TRUTH
Of the files from question 1, which one actually owns this behavior versus which ones are
consumers that would break if the source of truth's shape changed underneath them.

QUESTION 3 — IS IT DUPLICATED
Any place this same logic exists a second time instead of being called from the source of truth,
even a partial duplicate that only handles a subset of the real cases.

QUESTION 4 — GIVEN WHAT I ACTUALLY PLAN TO DO
I intend to add a new 'trial' tier between free and paid that expires after 14 days. Of the files from question 1, which specifically need a matching
change for that intent to hold, and which do not — and for each file you say does not need a
change, state briefly why it is safe as-is, not just that it was not obviously affected.

RULES FOR THIS ANSWER
- Do not propose the change itself yet. Answer only the four questions above.
- If a file plausibly should exist given how a feature like this is usually built, but you have
  not actually located it in this workspace, say 'not found in this workspace' rather than
  describing it as if you had found it — an inferred file that sounds right is worse than an
  honest gap, because it sends me looking in the wrong place with false confidence.
- Limit the search to lib/billing/ and lib/api/middleware/ — this has never lived in components/.
- If two files from question 1 appear to handle the same case differently, name the discrepancy
  explicitly under question 3 rather than only under whichever question you answer first — a
  reader working through this answer top to bottom should not have to notice the same fact was
  quietly relevant to two different questions.

This is a pre-refactor audit — err toward over-inclusion rather than a quick best-guess list.

IF THIS BEHAVIOR HAS COME UP BEFORE IN THIS CONVERSATION
If an earlier turn in this same chat already touched on where how a user's subscription tier is determined for feature gating lives,
re-verify against the current state of the workspace rather than repeating what was said earlier
without checking — a file can have moved or been refactored since that earlier turn, and an answer
here that is just a restatement of an earlier answer defeats the reason to ask again before making
a change.