OpenConceptLab/ocl_issues#2644 | fix Remove Resources by Reference dialog feedback and radio grouping

[jamlung-ri]

Problem

MSF reported (ocl_issues#2644) that clicking Execute in the "Remove Resources by Reference" dialog often showed no feedback at all — no success toast, the dialog stayed open, and the page didn't refresh — even though the removal had actually succeeded server-side (confirmed only by manually refreshing the page).

Root-caused to two separate bugs in CollectionHomeChildrenList.jsx:

1. Feedback suppressed on the plain-delete path. onExecute called deleteReferences(referenceIds, false), hardcoding alert=false. Since deleteReferences only shows a toast / closes the dialog / reloads when alert is true, choosing "Remove reference(s)" — the recommended action for the common case where a resource is covered by exactly one reference — produced no feedback whatsoever. The only reason feedback ever appeared was if an "Exclude" action also ran in the same execute (excludeReferences had its own success handling), so this was invisible unless a mixed selection happened to be made.

   Related: excludeReferences's own success handler ignored the response status entirely, so a 202 (request queued as an async Celery task, per TaskMixin) was reported as an unconditional "Successfully executed" instead of a queued-status message — unlike the equivalent handling already present in ReferenceForm.jsx for Add References.

2. Shared radio-group name across rows. Each selected resource's row renders its own RadioGroup for choosing "Remove reference(s)" vs. "Exclude concept(s)/mapping(s)", but every row used the same literal name="reference-action". Native HTML radio-button grouping is scoped by name across the whole page, independent of React component boundaries — so with more than one resource selected, all rows collapsed into a single mutually-exclusive group. Only one radio in the entire dialog could end up checked, regardless of which action was actually recommended for each row.

Solution

• onExecute now collects whichever of the delete/exclude requests actually fire into a single Promise.all, and a new onExecuteComplete handler always closes the dialog and shows success/error/queued feedback once, based on the actual response status(es) — including surfacing 202 as "queued" instead of a false "success".
• Scoped each row's RadioGroup name to resource.uuid, so multi-resource selections no longer interfere with each other's default/checked state.

Test plan

• Reproduced against a local OCL instance seeded via ocl-cli: a concept with a single reference (delete path) and a concept with two overlapping references (exclude path, including a queued 202 response).
• Verified pre-fix: selecting only the single-reference concept and executing showed no feedback and left the dialog open; selecting both concepts together showed inconsistent/wrong default radio selections.
• Verified post-fix: single-reference delete now shows a toast, closes the dialog, and reloads; multi-resource selection shows each row's own correct recommended radio checked independently; queued (202) responses show a "queued" message instead of false success.
• eslint clean on the changed file.

Refs OpenConceptLab/ocl_issues#2644