I guess the hardware is shipping now?  So, time to release.
I never heard back about some calibration details, particularly about
whether the floor level is reliable on many items or just mine...
but I guess it must have been fine if it's shipping.

* wurkkos-ts26:
  calibrated for latest TS26 sample
  wurkkos-ts26: increase default floor to 5/150 to reduce flicker (by request)
  renamed wurkkos-ts25-boost to wurkkos-ts26
  wurkkos ts25-boost: calibrated for 20250210 prototype
  ts25-boost: calibrated for new prototype - battery voltage readings - RGB button aux - less moon flicker (but brighter, less efficient moon) - reduced blink brightness   (old brightness was so high it was throwing off battery readings)
  ts25-boost: reduced visible PWM, made party strobe less blurry
  wurkkos-ts25-boost: calibrated the battery voltage measurements
  attiny1616 mcu_vdivider_raw2cooked: factor in the offset, not just slope
  added wurkkos-ts25-boost (early version made from spec, no clue if it works)

# Conflicts:
#	MODELS

It's the same as &hank-emisar-d3aa, but needed some minor tweaks:

- wait longer before measuring the battery,
  because it's hard to tighten the tailcap fast enough

- ramp adjustments to compensate for slightly different "gear ratio"

It won't light up below DSM 10/32640, and is really unstable.
Wurkkos wants no flickering on the lowest mode, so I raised
the floor to 20/32640, which is as low as it can go.

So, no real "moon" mode on this light.

(side effect: also enables RGB front aux while main LEDs are on,
 since the two are a single circuit internally and can't be separated)
(changed at Hank's request)

(by request)

(the product name changed upstream)

- changed from RGB button to RGB front aux
- complete recalibration of voltage sensor
- had to change party strobe timing to make it work again
- still couldn't fix moon, it's flickery AF no matter what I do

* trunk:
  lockout mode now only does momentary moon/low on 1st and 2nd presses, so it no longer flashes on each click while advancing to other functions
  emisar-d3aa: reduced preflash by changing timing of power enable steps
  fix "Error: Missing download info for actions/upload-artifact@v3"
  fixed model number of hank-lume-x1 in MODELS
  Added changelogs for 2025-04-29 release.
  memester egg (was written a long time ago on a whim and never committed,  may as well do it now)
  changed hank-lume-x1 model number back on 2024-09-28 for some reason, and didn't commit... saving now to change branches, but should delete this commit if it turns out there was no reason for it
  hank-lume-x1: minor calibration and cleaning - calibrated party strobe - removed duplicate or commented-out code - added a basic readme
  hank-lume-x1 cleanup and calibration, part 1: - changed model number from 0281 to 0171 - cleaned up blink_negative and AUXLED_RGB_DIFFERENT_PORTS a little   (but the latter needs a complete refactor, as soon as the    hardware abstraction code can handle aux LEDs better) - cleaned up USE_LONG_BLINK_FOR_NEGATIVE_SIGN a little - removed USE_OTG_IN_MOMENTARY since it's not actually used - moved hw/loneoceans/lume-x1-avr32dd20/* files into hw/hank/lume-x1/ - superficial cleanup on hank/lume-x1/hwdef.* - removed some of the extra stuff from hank/lume-x1/anduril.h - adjusted calibration (especially ramp table) on hank-lume-x1   (ramp shape is pretty close to a D4K-boost now, but with more firefly modes)   (calibration is based on a sample size of 1, further testing needed)
  cherry-picked hank-lume-x1 code from https://github.com/loneoceans/anduril/commit/d83ebb75dab8c462b7efa841bccc00a136ff15a2
  merged SammysHP's fix for TS10 lower-Vf LEDs, reverted my fix (they are now two separate build targets)
  wurkkos-ts10-rgbaux: limit max power to 200/255, at Wurkkos's request (because otherwise the light destroys its own LEDs at full power)
  Add Wurkkos TS10 RGB with reduced FET output

After testing on every device I can, and getting several users to also
test this, it appears to reduce and sometimes completely eliminate
preflash on most devices... and the cases where it wasn't reported to
help, at least it didn't make things worse.  Some units apparently just
can't get the flash eliminated completely, despite trying lots of things.

Instead of turning the chips on and then waiting 4ms, it now turns the
preflash absorber on, waits ~0.6ms, sets misc params, then turns the
boost chip on, then waits ~0.6ms, then turns the preflash absorber off.

This seems to work best on li-ion power, where on my devices it completely
eliminates any preflash.  There is still a very mild flash on AA though,
which I wasn't able to get rid of.  But it's like... 0.003 lm for just
a few milliseconds, really not bad.  Even in the worst case reported by
a user, based on the video they took, it looks like just 0.01 lm for
a few milliseconds.

for some reason, and didn't commit... saving now to change branches,
but should delete this commit if it turns out there was no reason for it