feat(faces): dissolve a contaminated person from the face cleanup console

[Deeds67]

Adds a way to dissolve a person from the admin face cleanup console, for people that have accumulated faces which aren't them.

What it does

Two axes, chosen independently:

• Which faces — all, exif (imported from file metadata), machine-learning, or without-embedding
• What happens to them — unassign, delete-faces, or delete-faces-and-person

Plus the discovery listing needed to find such a person in the first place: a Health tab on /admin/face-cleanup/people showing each person's face count broken down by source, sortable by the contamination signals. A cleanup scan can't surface these people, because it only looks at faces that have an embedding.

Repair happens on the next detection run. A dissolve clears asset_job_status.facesRecognizedAt for exactly the affected assets. Since streamForDetectFacesJob applies its facesRecognizedAt IS NULL filter only when force === false, the ordinary "Detect faces (missing)" pass re-processes precisely those photos — no library-wide rebuild.

The scope axis exists because the two cases need opposite handling: metadata-imported faces have no embedding and can never be re-clustered, so deleting them is the repair; mis-clustered ML faces have embeddings that should survive and be re-clustered.

No migration — all six referencing foreign keys already cascade.

Safety

The operation is irreversible, so the preview does the work: counts split by source and embedding presence, how many photos also contain other people, how many can never be re-detected, six warnings, and a typed-name confirmation.

Three behaviours worth knowing when reviewing:

• Nothing library-wide is ever triggered. deleteAllOrphanedPersons() is instance-wide and PersonCleanup deletes faceless people library-wide; neither is reachable from a dissolve. This holds transitively — the AssetDetectFacesQueueAll { force: false } a dissolve queues skips both the if (force) branch that calls them and the force === undefined branch that queues PersonCleanup.
• Re-detecting a shared photo can remove another person's face if the detector no longer finds it. Accepted rather than solved — avoiding it would mean skipping repair on the photos that need it most — and surfaced as a count. Pet co-occupants are excluded from that count, since handleDetectFaces keeps pet faces out of faceIdsToRemove.
• Hidden, trashed and preview-less assets can never be re-detected, so the dialog counts them separately and doesn't promise repair for them.

Testing

Medium tests against a real database carry the load — the cascades and the re-detect gate are invisible to a mocked repository. The isolation fixture is built so a missing WHERE clause can't pass it: two people of the same user sharing an asset, a pet person, a second user, a shared space holding an orphan that pre-dates the run, an unrelated faceless person, and a face_identity shared across two people with one side manually placed.

Assertions were checked by mutation rather than assumed — each guarantee verified to fail when the thing it protects is broken. That caught a pet-exclusion assertion that couldn't fail under any single-fault break, four preview counts that looked covered and weren't, and a test whose title claimed more than its body checked.

Server unit 6405 passing · face-dissolve medium 27/27 · web 362/362 · one end-to-end run driving discovery → modal → HTTP → database, asserting both the deletion and the cleared watermark.

Known before merge

• OpenAPI/SDK output was regenerated by hand (build → sync:open-api → oazapfts → SDK build → dart script), because //-prefixed mise tasks run against the main checkout rather than a worktree. Worth knowing for review: the OpenAPI Clients check verifies the spec and TypeScript SDK regenerate clean but never compiles the Dart client — only Unit Test Mobile does. It caught one real defect here, an anonymous enum on a body property that the Dart generator references as OutcomeEnum and then never defines; both request enums are now named schemas.
• ORDER BY on an aggregate alias means LIMIT/OFFSET prune nothing, so each page of the Health tab re-aggregates that owner's faces. Measured below at ~50ms/page; keyset pagination is the follow-up if it ever bites.
• The face delete dominates a dissolve at roughly 124µs/face, in one statement holding a write transaction. ~0.9s for 6.9k faces; a 50k-face person would hold it ~6s. Fine for an admin-triggered one-off, worth knowing before someone runs it on a much larger person.

Measured against a real library

Validated on a throwaway clone of a real 2,344-person / 60,253-face library (~8× the people and 10× the faces of the seeded benchmark), connected as the gallery role so the per-role jit=off actually applied.

The discovery aggregate holds up: 55ms for page 1 and 49ms for a deep page at offset 2250 — the face_search anti-join plans as loops=1, hashed once rather than re-run per row. A deep page costing the same as the first is what confirms the re-aggregation note above is real but cheap.

A dissolve of the largest real person (6,921 faces) was run inside a transaction and rolled back — real data measured without mutating it. Preview 29ms, watermark clear 104ms, face delete 861ms, person row 5ms; ~1.0s total. The isolation property the test matrix exists for held on real data: people 2344→2343 (exactly one), faces 60253→53332 (exactly 6,921, not one row more), 6,865 assets requeued. After rollback all three counts returned to their original values.

Worth noting as a negative control: this library is entirely healthy — zero EXIF faces, zero manual, zero faces without embeddings — so the Health tab correctly reported all-zero contamination columns rather than inventing candidates. No genuinely contaminated person existed here to dissolve for real.

https://claude.ai/code/session_017Sw5EMqwWaHxAfybKgFxmP