Bulk review triage + auto-merge for identical-name/same-type duplicates

[realestate-aistudio]

Pain

After ingesting a 291-section CSV, the review queue flooded: 1500+ resolution rows, 500+ manual clicks in one session. Single-item decide only (POST /review/{id}), no bulk endpoint, no multi-select that works at this volume.

Evidence from our KB

• 1137 rows auto-kept by adjudication, 159 kept by hand, only 61 auto-merged.
• Of 50 pending 'namesake' (score 1.0, identical canonical_name) pairs: 23 share the same entity type (safe merges), but 28 have CONFLICTING types (homonyms - same string, different meaning). Blind auto-merge would corrupt those 28.

Proposal

1. Bulk decide API + working multi-select in Review UI (the current select-all does not scale to hundreds).
2. Optional auto-merge ONLY for identical canonical_name AND same type_id (both set, equal), still logged + revertible via revert_merge. Never on type conflict.
3. Surface the type conflict in the duplicate row (today the row shows two similar names; the decisive info - same vs conflicting type - is invisible, forcing users to open each pair).

Environment: v0.1.0-rc5 (server), dev observed for code paths.

[WaylandYang]

Thanks — the numbers make this easy to act on. Taking it in two cuts, capability first:

1. Bulk decisions. POST /kbs/{id}/review/batch with a list of review ids and one action (merge or keep); each decision is applied and logged exactly as a single one is, and the response says which ids went through and which did not. Then multi-select in the review page on top of it — there is no working select-all today, so this is new rather than a fix.
2. Auto-merge on identical name + same type: not blind. Your own count is the argument — 28 of 50 identical-name pairs were homonyms — and "same type" is not identity either (two people named Zhang Wei are both Person). The base's stance is that a namesake tie goes to a person, never to a coin flip. What you will get instead makes that person fast: the duplicates queue gains a filter for same name, same type (and its opposite, type conflict), so the 23 safe-looking pairs are one screen and one bulk merge — a human's click, logged, revertible through revert_merge like any merge.
3. The type conflict on the row. Each side already shows its type, but not the fact that they differ; the row gets an explicit mark (Person / Organization) and the filter above sorts on it.

Will link the PRs here.

[WaylandYang]

One more thing, since it bears on your point 2: automatic governance is close on the roadmap — policies a base sets for itself (for instance "merge identical-name, same-type pairs the adjudicator scores above N; keep the rest for a person"), running on the same ledger and with the same undo as a decision made by hand. The filter and bulk action above are the manual half of that; the automatic half will go through the same batch endpoint, so nothing built here gets thrown away.

[WaylandYang]

Shipped in two cuts, both on dev now:

• Duplicates can be decided in a batch and filtered by type #429 — batch decide API (POST /kbs/{id}/review/batch, {ids, action}, up to 500 per call, one audit row per decided pair) and a ?types=same|conflict filter on the duplicates queue.
• The duplicates queue filters by type and decides a page at a time #430 — the Review page: a Same type / Types differ filter with counts, a checkbox per pair, "Select this page", "Merge selected" / "Keep selected apart", and a "types differ" mark on the row.

Automatic governance is next; it will read the decisions people made here as its precedent.