Set the count-in length, and accent a song in an odd meter

[thcp]

Two changes to the click panel, one commit each.

Closes #587
Closes #593

Count-in length

The count-in was one bar, fixed. The reporter asked for more clicks: at 120 BPM in 4/4 there are two seconds between pressing play and the song arriving, which is not long enough to get a hand back to an instrument.

It is now a length select: off, or 1 to 4 bars. Off is the zero case rather than a separate toggle, since once "how many bars" is a question a toggle beside a length is two widgets for one setting. That replaces the press-to-arm button, so "armed" reads as a non-zero value and the tint moves to the select wrapper.

Bars, not a literal click count, which is what the request named. Both implementations derive clicks as countBars * beatsPerBar -- computeCountIn in static/js/metronome.js and count_in_beats in app/pipeline/click_render.py, which are held to each other beat-for-beat by tests. A raw click count would break the downbeat alignment in every meter. In 4/4 the bar lengths already give 4, 8, 12 and 16 clicks, which is the span the request was about.

Exports follow the transport setting. The export query cap moves from 2 to 4 to match -- it sat below what the UI can now ask for, so picking 3 or 4 would have 422d the export while playback counted in fine.

The stored preference changes from a countIn boolean to countInBars. The old key is still read when the new one is absent, so an existing user keeps their count-in armed across the upgrade rather than silently losing it.

Odd meters

The click offered 2/4, 3/4, 4/4 and 6/8 and nothing else, so 5/4 or 7/8 could not be accented correctly. Auto was not a general answer: it follows detected bar marks, which on an odd-meter track are the marks most likely to be wrong or missing, and when they are missing Auto is disabled outright.

Adds 5/4, 7/8, 9/8 and 12/8, plus a "Custom..." option revealing a number input for anything else.

Nothing underneath needed changing, which is the point. beats_per_bar was already validated ge=1, le=32, the beat-grid editor already exposed a free number input over the same range, the count-in maths was already meter-agnostic, and the render cache key already includes the bar signature. The <select> was the only thing narrowing the range.

A typed value is clamped into 1..32 rather than rejected. An unparseable one falls back to 4 rather than Auto, since the user explicitly asked for a custom meter.

The denominator stays cosmetic. "7/8" means seven beats per bar, not a subdivision change. There is no note-value concept in the app, and adding one would reach click rate, count-in tempo and the cache key. Out of scope here, and noted on #593.

Verification

All run locally on macOS arm64:

Gate	Result
ruff check / ruff format --check	clean
pytest tests/ -q	997 passed, 2 pre-existing failures
node --check static/js/*.js	clean
tests/js/*.test.mjs	all 12 suites pass
npx playwright test	128 passed
bandit -r app/ -ll	exit 0
bash -n run.sh	clean
i18n drift check (from .claude/rules/i18n.md)	clean, all 11 tables

The two failures are test_all_stems_zip_ogg and test_ogg_is_still_streamed. They fail on unmodified main on this machine too -- the local Homebrew ffmpeg ships only the experimental native vorbis encoder, not libvorbis. Verified by checking out main and re-running them.

New coverage: 4 count-in lengths through the export API, lead-in arithmetic across lengths, 1-4 bar shapes and a 7/8 count-in in the JS parity test, and two e2e tests driving the real controls in a browser -- including that a typed 99 clamps to 32.

Both commits were verified green independently, so the intermediate commit is not broken.

Note the i18n rule says 8 language tables; there are now 10 (es and ko were added since). New keys went into all of them.