fix: the same row again is the same selection

[xAlcahest]

Summary

useCueSelection's move(index, "plain") called setSelected(new Set([index])) whatever the selection already was, so clicking the row that is already the only selected row handed React a new object with the same member and everything that reads the selection rendered again. setActive beside it was already a no-op, because React compares the value.

Interface-spec §7.2 asks for this outright, and says why: a redundant announcement in React is a redundant render. It was parked because it could not be proved from outside, and the instrument that would have proved it, a render counter published in the DOM, was judged heavier than the defect. That judgement is out of date: the keydown counter added earlier today is one attribute write inside an effect that already exists, and the same shape works here.

Closes N159.

Changes

• src/hooks/useCueSelection.ts: a plain move keeps the selection it has when that selection is already exactly the row asked for.
• src/components/CueList.tsx: an effect with no dependency list counts the grid's commits on the root element, which is what makes a render that happened for nothing readable at all.
• e2e/specs/grid-selection.spec.js: a check that clicks the row the cursor already holds and reads the count back unchanged, then clicks another row as the control.
• e2e/wdio.conf.js: the count guard goes from 515 to 516.

How to verify by using the app

Nothing visible changes, which is the point: the grid is virtualised, so the work saved is bounded by the rows on screen. Click the row the cursor is on and nothing flickers, as before.

Verified on Linux. Full gate green, 87 spec files and 516 tests in 5:55, verdict line GATE GREEN. Proved by a mutation in the build: with the unconditional new Set([index]) back, the check reads Expected: 32, Received: 33, which is the one redundant commit this closes, counted rather than argued.