drag_and_strum still preloads audio on every shifted keystroke while typing

[vitalibondar]

#2978 fixed the listener leak in drag_and_strum_controller (thank you — that was the bulk of the problem), and #2926 is closed. There's a second, smaller cause of the same symptom still present on main, so I wanted to raise it here rather than reopen anything.

What's left

handleKeyDown still runs on every document keydown, including while typing in a comment box:

handleKeyDown(event) {
  if (event.shiftKey) {
    this.instrumentIndex = this.#getInstrumentIndex(event)

    if (this.instrumentIndex < INSTRUMENTS.length) {
      this.#preloadAudioFiles(this.instrumentIndex)
    }
  }
}

Every shifted keystroke while composing a comment — capitals, !, ?, : — re-enters #preloadAudioFiles and constructs six new Audio() objects. With the leak fixed this now happens once per keystroke instead of once per leaked listener, so it is far less severe than before, but it is still real work on a hot path that has nothing to do with dragging.

Suggested fix

The strum is only meaningful during an actual drag, so keydown originating from a text field can be ignored:

#isEditingText(event) {
  const el = event.target
  return el?.isContentEditable ||
         !!el?.closest?.("input, textarea, select, lexxy-editor")
}

…checked at the top of handleKeyDown. The easter egg during a real drag is unchanged.

One caveat worth flagging: a naive version that treats every <input> as text entry would also swallow button/submit inputs, so the guard should be written to skip those.

Status

My original #2929 bundled this together with the same leak fix you shipped in #2978, so it's now half-redundant and conflicts with main. I'm closing it and raising just the remaining half here, per CONTRIBUTING. If you'd like this change, I'm glad to open a fresh, minimal PR against current main — or to leave it alone if the cost is considered acceptable for an easter egg.