cv_trigger: a host-sized input count, and MIDI notes reach a CV note output

[bwhitman]

Three things found bringing a MIDI->CV converter (a Kenton Pro Solo) to a board whose gate input is a GPIO, not an ADC channel:

• AMY_MAX_CV_IN is #ifndef now, and update_external_cv_in loops over it, so a host can build with -DAMY_MAX_CV_IN=3 and answer amy_external_coef_hook for a channel that is not analog at all -- a gate pin read as 0 or 5 V. A cv_trigger can then fire off a gate jack with no ADC input spent on it. Default and web behaviour unchanged.
• A MIDI note now reaches a CV_GATE note output. note_output_handle_event refused any note carrying note_source_channel unless forward_midi_in, a flag only MIDI_OUT mode can set. The feedback-loop guard is right for a MIDI port and has no loop to guard against on a jack, so a MIDI keyboard never moved a CV/gate output. The guard applies to MIDI_OUT only now.
• An empty velocity field stays unset. note_output='1,0,2,,12,24' (the doc's own example) cast the unset arg to channel 0, so every note-on wrote its velocity over the pitch DAC.

Docs: cv_trigger's scale and offset are octaves with 0 at ZERO_MIDI_NOTE (midi_note_for_logfreq), not semitones, which api.md now says; cv_pitch_for's comment claimed to be that formula's exact inverse in semitones and now says how the two convert.

🤖 Generated with Claude Code

[dpwe]

This is confusing. I can imagine a situation where ext_coef_in(2) actually reads a gate input, but AMY knows nothing about how that function interprets its arg. The comment seems to imply something more specific.

[bwhitman]

Agreed -- that comment described what one host does with channel 2, and AMY has no view of that. Reworded to what AMY actually knows: the count of channels update_external_cv_in asks the hook for and the range a cv_trigger may name, with what a channel physically is left to the host.

[github-actions]

🎛️ AMY HW CI (AMYboard bench)

Flashed this PR's AMY (LoadTestChord: 6-voice Juno patch=1, one held note every 2 s) onto the physical AMYboard and measured the smoothed render load as the chord grows — back-to-back with the same sketch built at the PR's merge base, so Δ is this PR's own cost.

✅ PASS — the bench ran the test to completion.

notes held	main @ 29cd07c	this PR	Δ
1	987	976	-11
2	1142	1131	-11
3	1714	1700	-14
4	1883	1872	-11
5	2472	2457	-15
6	2609	2596	-13

Full chord settled render μs: 2597 (was 2608, Δ -0.4%) (peak 2602, 39 samples)

⬇️ Artifacts: serial log · load trace · report

_{Self-hosted bench (amyboardci). FAIL means only that the test could not run — the load values are informational, with no threshold and no audio compare. See tools/arduino_loadsweep/.}

[bwhitman]

⛓️ tulipcc integration PR opened

This merge was pinned into tulipcc for full-system CI: shorepine/tulipcc#1372

Test it there and merge that PR to move tulipcc onto this AMY.