Data remediation for the firm-account stranding fixed in code by PAR-315 (and [[PAR-141]]). The code fixes are on develop but a release is ~a week out, so prod can still accrue stranded accounts until deploy.
When a firm's proprietor changed — via player transfer (PAR-141, undeployed) or /firm admin set proprietor (PAR-315) — the corporate account's owner_uuid_bin / account_authorizers / account_members were left on the previous proprietor, so the new proprietor gets "you're not an authorizer" and can't touch the firm's money.
/firm admin set proprietor until deploy, which removes the admin-path source. The player-transfer path can still strand an account on any accepted transfer until the code ships, so re-run after transfers or on a "can't withdraw" report.ops/backfill-firm-account-owners.sql — 5 standalone, idempotent statements (no temp table / transaction / SET; runs top-to-bottom in any client). Aligns every active firm account's owner + active member + active authorizer with firm.proprietor_uuid_bin and revokes the previous owner's stale access unless they're a current employee.
Check whether a re-run is needed (0 = clean):
SELECT COUNT(*) FROM firm f
JOIN firm_accounts fa ON fa.firm_id=f.firm_id AND fa.removed_at IS NULL
JOIN accounts a ON a.account_id=fa.account_id AND a.is_archived=0
WHERE f.is_archived=0 AND a.owner_uuid_bin <> f.proprietor_uuid_bin;
Knobs: add AND f.firm_id NOT IN (3113,3122,3144) to each WHERE to hold back the Planke32 firms; skip statements 3 and 4 to leave prior owners' access in place.
PAR-141 + PAR-315 are deployed (code then maintains the invariant automatically). Until then this stays open as the ad-hoc remediation.
Refs: PAR-315 (code fix + script ops/backfill-firm-account-owners.sql), PAR-141.