The per-account access tiers were six tables — account_members / account_authorizers / account_viewers plus LuckPerms-group variants — for what is really one ordered capability scale: VIEWER (read) < MEMBER (read+spend) < AUTHORIZER (read+spend+manage). An authorizer was already required to be a member (composite FK), confirming the linear nesting; authorizer is just "member + can-manage". The viewer tier (PAR-237) made the sprawl obvious.
Collapse to two tables — account_access(account_id, subject_uuid_bin, level ENUM('VIEWER','MEMBER','AUTHORIZER'), …) and account_group_access(account_id, lp_group, level, …) — one row per (account, subject) carrying the highest level. MySQL ENUM ordinal ordering gives clean tier checks (canView = any active row, isMember = level ≥ MEMBER, isAuthorizer = level = AUTHORIZER).
Timed before PAR-237's V18 (account_viewers) reaches prod: fold it into V18 — rewrite the unreleased migration to create the consolidated tables, backfill the existing V1 members/authorizers, and drop the six legacy tables. account_viewers never ships.
Blast radius: treasury (MembershipMapper/GroupMembershipMapper + MembershipServiceImpl + tests), treasury-rest-api (read mapper), economy-explorer (canReadAccount + fixtures). The MembershipService/TreasuryApi method surface stays stable, so business (API-decoupled) and GovCommand are unchanged. Follows PAR-237.