PR #7379 — a household names its co-resident

Live Preview: the branch's own dev server (npx next dev --port 3099), signed in as the smoke account, reading stage data. Names and numbers on stage are synthetic. Captured 2026-09-08 with Playwright at 1440×1000.

Before — main

/tenants?sortBy=unit&filterStatus=Active. One bare row per person: two residents on one lease are indistinguishable from a duplicated row.

Before: the tenants list on main, sorted by unit, Active only — 124 of 179.

After — this branch, stage data

Same URL. Stage's only multi-row groups (two, at units TEST-204 and TEST-312) each share ONE AppFolio tenant id across their two rows (appfolioTenantId 1845 / 1846, pmsOccupancyRef 995 / 996 — distinct id spaces, so not a seed artifact); one pair is the same Person twice, the other is two Person rows. The brief's same-AppFolio-id rule says both render as one resident and flag nothing, so the page is visually unchanged here, and that is the correct outcome. Whether the two-Person pair is a duplicate or a mis-keyed household is the dedup task's call, not this PR's.

After on stage: identical rows and count (124 of 179); the duplicate pairs carry no co-resident line and no flag.

row count 50 on page 1, count text 124 of 179 — unchanged from before
zero co-resident lines on stage, because stage holds no household with two distinct AppFolio tenants
no page errors

After — this branch, two synthetic rows injected

The same page with a synthetic household (two residents, two AppFolio tenant ids, one occupancy ref) and a synthetic duplicate pair (one AppFolio tenant id twice) added to the /api/tenants response by Playwright request interception. Browser-only: nothing was written to any table. Unit 000/001 so they sort first.

After with synthetic rows: each household row reads "+ Name · co-resident" beneath the resident, linked to the other person's page; the duplicate pair renders as two plain rows.

two co-resident lines — one per household row, each naming the OTHER resident
co-resident links: /tenants/demo-hh-b on A's row, /tenants/demo-hh-a on B's row
the duplicate pair: no co-resident line, no badge, no flag
clicking the co-resident link on A's row navigated to /tenants/demo-hh-b (a cross-link, not the row's own page)
count text 128 of 183 — 4 synthetic rows, 4 more tenants: one row, one person

Why annotate rather than fold

The brief asked for one row per household. Gera, 2026-08-31 (#6685), on the sibling prospects list: "I would count co-applicant people as two … but I would make that consistent throughout." That list folded to households in #6647 and un-folded the next day. This list follows the ruling: one row per resident, each naming its household. The fold is a contained client change if the owner wants it.