Batch-edit rating / tunes / customFields in Collection multi-select (follow-up to #409)

[ibanner56]

Summary

Follow-up to #409. Batch set/clear level landed in multi-select via PR #422. This issue tracks extending the Collection multi-select "batch edit" affordance to the remaining per-dance metadata that make sense to bulk-edit.

Background

#409 originally read as "bulk-add tags," but batch tag add/remove already shipped in #93, and the genuinely new ask ("add metadata like level in multi-select") was scoped down to level for one atomic, reviewable PR (#422). The remaining metadata fields were deliberately deferred here.

Scope

Add batch edit for the following, each as its own atomic PR where practical, reusing the setLevelForMany transactional pattern (one transaction, idempotent skip, changed-count, Undo, AT announcements, empty no-op):

• rating — batch set/clear (Dance.rating, clearRating).
• tunes — semantics TBD: additive union (like tags) vs replace. Needs a product decision before implementation.
• customFields — set/clear a chosen key across the selection; needs UI for choosing which field + value. Larger; may warrant its own design note.

Guardrails (carry over from #409)

• core stays Flutter-free; new batch mutations go through a single transaction in DanceRepository (no half-updates).
• Idempotent (skip dances already at target), return changed count, Undo restores prior per-dance values, AT announcements, empty-selection no-op/disabled.
• a11y: pickers expose role + text label (never color alone), mirroring batch_level_dialog.dart.

Out of scope

Anything already shipped (tag add/remove #93, level #422).

[ibanner56]

Triage: confirmed — well-scoped follow-up to the batch-edit work. #409 is closed, level shipped via #422, and this correctly tracks the remaining bulk-editable metadata. Keeping type: enhancement + area: collection.

PM notes on the three sub-items, in order of readiness:

• rating — ready to build now. It's a direct analogue of setLevelForMany (transaction + idempotent skip + changed-count + Undo + AT announcement + empty no-op), reusing the batch_level_dialog.dart pattern with a star picker. Atomic, reviewable, and a reasonable good first issue once carved out. Recommend this is the next PR.
• tunes — blocked on a product decision. Two clean semantics: additive union (mirror the tag add/remove model — least destructive, composes across a mixed selection) vs replace (overwrite the field for all selected). My lean is additive union to match the tag precedent, with a separate "clear tunes" action; a destructive replace is surprising in multi-select. Flagging for an explicit decision before implementation.
• customFields — largest; warrants its own design note before coding. Needs UI to (a) pick which custom-field key to edit across the selection, (b) enter/clear a value that respects the field's type (text/number/choice), and (c) decide behavior when a selected dance lacks that field. Suggest splitting into a design issue + an implementation PR.

Guardrails from #409 carry over unchanged (core stays Flutter-free; single DanceRepository transaction; idempotent; Undo; a11y pickers expose role + text label, never color alone).

Moving off triage → confirmed. Priority low overall (deferred polish), but note the rating slice is the actionable near-term piece and could be promoted independently.