Configurable per H-bridge ETB duty ceiling (#9799) - #10086

ETB_DUTY_LIMIT was a hard-coded 0.9, applied through the ETB_PERCENT_TO_DUTY
macro at the single point where the controller writes to the motor. The
reporter's H-bridge trips its own overcurrent/thermal protection as the PID
pushes duty toward that ceiling, on a throttle which is mechanically wide open
around 45% duty - so the top half of the range is not merely unused, it is
actively harmful on that hardware.

The limit is now engineConfiguration->etbMaxDutyCycle[ETB_COUNT], default 90.

90 stays both the default and the upper bound. This issue is about lowering the
ceiling; letting a tune raise it past what the hardware was always limited to is
a separate call with hardware-protection implications, so the field range stops
at 90 rather than 100. Easy to relax if that is not the preference.

0 means "not configured". Tunes predating the field read 0, which would
otherwise mean "never open the throttle". applyDefaultsOrFixAfterBurn maps it to
90 per docs/calibration-compatibility.md, and getMaxDutyCycle() independently
falls back to 90 for anything outside the valid range, so even a config reaching
the controller before migration runs cannot shut the throttle. Two layers on
purpose, given what this path controls.

init() keeps its signature - it is a pure virtual with roughly two dozen call
sites in the tests. The H-bridge index is instead recovered by finding this
controller's function in etbFunctions[], which is the array that defines the
mapping in the first place.

Full unit test suite: 1164 pass, up from 1159. Host build only; no ARM firmware
build was run locally, and this is not tested on hardware.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

startBenchTest() and doAutocal() drive the motor with a fixed 0.5 duty rather
than going through setOutput(), so they ignored the configurable ceiling
entirely. On the hardware which motivated this issue that is the worst case:
50% is above the limit the user lowered the ceiling to in order to stop the
driver faulting, so the two paths most likely to be run on the bench were the
two that could still trip it.

New clampToMaxDutyCycle() is used by all three call sites.

Trade-off worth flagging: autocal can be less accurate on a throttle which
needs more than the configured ceiling to reach its mechanical stops. Exceeding
a limit the user set for hardware protection is the worse of the two.

Full suite: 1172 tests pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…TY_CYCLE

default_base_engine.cpp uses the constant but never included electronic_throttle.h,
where it lives. The unit test pch happens to pull the header in, which is why the
test build passed while all 51 firmware/simulator CI jobs failed with

    default_base_engine.cpp:152: error: 'ETB_DEFAULT_MAX_DUTY_CYCLE' was not declared

The header is already compiled in every build context via engine_controller.cpp
and engine_configuration.cpp, so including it here is safe everywhere.

Local verification: full unit suite passes (1172 tests). The 32-bit MinGW
simulator toolchain CI uses is not available on this machine, so the simulator
build itself is left to CI - the include is what the error asked for.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUaUv4kBBZhtCkMpZnh8So