Fix the flaky pad-editor test at its cause (#290)

[thorwhalen]

Closes #290: the flaky test/drum_pads_editor.test.tsx. This fixes the cause instead of raising the test timeout.

Two causes, both real

1. A race (seen on CI tonight, on PR @thoremin/sdk: the pure extension SDK as a workspace package (ADR follow-up c, part 1) #298). The walk waited for the "Air instruments" group, then looked up "Edit Air Drum" synchronously. The group renders before the seeded instruments arrive, so the lookup failed after 343 ms with "Unable to find a label ... Edit Air Drum". The test now waits for the row itself.

2. Load. Every dial write re-rendered the whole Instruments view. The walk took ~0.7 s alone and over 5 s under the full suite's parallel load: the timeout reported in Flaky test: drum_pads_editor.test.tsx times out (~5.2 s) under full-suite load, passes alone #290. It is now split in two:

   • the cold-load reachability (to the editor, plus one write) stays on the real view;
   • the editing walk renders DrumPadEditor itself, against the same dials store and command path.

   Each walk resets the airDrum dial. Timings: 518 ms + 277 ms, where it was one 721 ms test.

Also, after review:

• the same race fixed in test/instruments_view_compact.test.tsx: its group() helper waited for any list item, and an empty group's "None saved" placeholder satisfied that before the seeded rows arrived. It now waits for a named row;
• the cold-load walk asserts the editor is the same element after a dial write, so the view's re-render cannot silently remount it (the editing state the colour-picker bug depended on);
• a first draft raised testing-library's waitFor timeout globally. It is dropped: the suite passes without it, and it would only have masked slowness.

Verified

• Full suite repeatedly, and under load (two and three concurrent 8-thread suites, by the reviewers): 2439 passed each time; the two files under --sequence.shuffle across seeds.
• npm run test:core passes; typecheck is clean.