feat(limits): smooth composable thermal + current ceilings, armed on ARK_G431_CAN

[AlexKlimaj]

Summary

Makes the thermal and current limiters two soft, composable, tunable duty ceilings, and turns both on by default for the ARK 12S CAN board. Stacked on #79 — the ARK_G431_CAN target and its factory JSON only exist there, so this targets that branch rather than ark-release.

Why they were off. default_settings[] in DroneCAN.c is the AM32 configurator skeleton, and both factory JSONs were seeded from it. Its bytes 43/44 are 141 and 102 — each just outside the range settings.c arms (70..140 °C, 1..100 raw = 2..200 A) — so every ARK ESC has shipped with both limiters silently inert. A DroneCAN param erase memcpy's that array back over the page, so the defaults had to move too, or "restore defaults" would quietly disarm a shipped ESC.

Changes

• Thermal is now a foldback, not a threshold. It was map([limit-10, limit+10] → [max/2, 1]) entered only at temp > limit, so one degree of overshoot stepped the ceiling from full authority to ~22% and one degree of recovery restored it — a bang-bang across the whole derate range, cycling on the board's thermal time constant. It also overwrote duty_cycle_maximum, discarding the low-rpm map and the post-desync ceiling hold (fix(limits): hold the low-rpm throttle ceiling across a desync #62). Now runtimeThermalLimitTick() runs at 1 kHz off a Q12 IIR of the die sensor (τ ≈ 64 ms — the raw reading is a whole-degree unaveraged conversion that dithers ±1 °C) and produces its own ceiling, falling linearly from the onset to a 10% floor. A proportional derate settles; a threshold cannot.
• Tunable slope. Foldback width is eeprom byte 184 / DroneCAN TEMP_DERATE_BAND (5..40 °C, default 15). There is deliberately no hard-cut mode to select — dropping a motor outright on a multirotor is worse than flying on a derated one — so the slope is the knob. 0xFF on any page that never wrote the CAN block is coerced in settings.c.
• Current ceiling is released when not driving. It is an integrator with no other reset, so a run that ended current-limited left it low and the next start was capped below min_startup_duty until the PID walked it back up.
• Ceilings compose by min() in setInput(), applied after the stall-protection boost — a boost that can push duty back through a protection ceiling is not a ceiling. Not a product: thermal at 50% and current at 50% must give 50%, not 25%.
• Current sense saturates instead of wrapping. actual_current is int16_t centiamps (327.67 A) while a 10 mV/A chain reads to 329.6 A, so raw >= 4071 overflowed negative and hit the < 0 clamp as zero amps — releasing the limiter, blinding the nFAULT OCP classifier and reporting an idle ESC, all at >326 A, i.e. exactly the currents the VDS trip exists to catch.
• Observability. ZC_STATS v7 publishes both ceilings, the applied one, raw + filtered die temperature and current. These limiters only ever lower duty, so from outside a derating ESC and a weak plant look identical (cf. the dcm_hold no-op in test_ceiling_hold.py). check-factory-image-ark.sh now gates bytes 9/10/11/43/44/184 against the product JSON and prints the armed state.

ARK_G431_CAN defaults

Setting	Value
Thermal foldback	105 → 120 °C (die), 10% floor
TEMP_DERATE_BAND	15 °C
Current limit	200 A (stored 100, 2 A/count)
Current PID	100 / 0 / 50 (unchanged)

200 A is the most settings.c arms, ~80% of the 250 A shunt rating: a backstop under the DRV8350 VDS trip, not a flight limiter. The 4IN1 F051 stays off — its shunt is shared by all four ESCs, so per-motor current limiting is not meaningful there, and its thermal placement has not been benched.

Gains: measured, not reasoned

Softening the current loop looks right and is wrong. The ceiling moves by pid_output / 10000 duty units per tick, and that integer divide is a dead zone — the loop is inert until the overshoot exceeds 5000/Kp centiamps, so Kp 10 would need 10 A before the ceiling moved at all. SITL heavy_13inch at an 8 A limit:

gains	regulated current
P=100/D=50 (shipped)	7.7 A
P=50/D=25	7.1 A
P=25/D=10	6.5 A
P=5/D=5	14.7 A — does not hold the limit

Upstream's gains stay, and the dead zone is documented at the call site so this is not re-litigated from theory.

Not in this PR

• The 105 °C onset needs a bench number. It follows professional 12S practice (APD / industrial T-Motor fold back around 110 °C) and sits inside the G4 die sensor's 30..110 °C factory calibration span, with full derate below the part's 125 °C junction limit. But those vendors read an NTC on the power stage and this reads the MCU die — if the die-to-FET delta on this board turns out large, the onset belongs lower. It is a DroneCAN parameter, so that is a config change, not a reflash.
• Current-sense calibration against a real load (SITL only here).
• faultErrorCount() is desync_happened + fault_stall_trips, so a gate-driver trip appears in the one-shot nFAULT LogMessage but never in the periodic esc.Status.error_count. Left alone deliberately — it changes an existing field's semantics.
• The 4IN1 F051 factory defaults (still off).
• default_settings[] is still upstream's everywhere else, so an erase also reverts e.g. max_ramp to 16 %/ms rather than the ARK 2 %/ms. Pre-existing hole in the erase path; wants its own fix.

Test plan

• make ARK_G431_CAN — flash 46757 / 111584 B (41.9%)
• make size-check-ark — PASS, F051 27080 / 27592 (this change costs +264 B of a tight budget)
• make factory-image-check — PASS both products; reports thermal=derate 105->120 C current=200 A for G431 and thermal=OFF (141) current=OFF (102) for the 4IN1
• make sitl + 5 new tests in Mcu/SITL/tests/test_duty_limits.py
• Mutation checks: restoring the old threshold map drives the ceiling to 1 and fails the continuity test; setting CURRENT_P=5 fails the load test at 15.0 A against an 8 A limit
• Full SITL suite A/B vs stock — no regression attributable to this change, details below
• Hardware: die-to-FET delta under sustained load; confirm the foldback engages and recovers smoothly; confirm current-sense calibration at load

SITL A/B detail

Both binaries built from the same tree (stock = #79 head), run back to back on the same host:

	failed	passed
stock #79	14	32
this branch	14	37 (32 + the 5 new tests)

Identical failure counts, but the failing sets differ by 5 in both directions — the signature of host flakiness, not a regression (a real regression adds failures without removing any). Every failure is a rpm=0 spin-timing or bench-map assertion on a slow container. The two failures that appeared only on this branch were re-run against both binaries:

• test_safety.py::test_dronecan_disarm_zeros_input — passes on both.
• test_bench_models.py::test_bench_steady_map_matches_hardware — fails on both, and on a different plant parametrization each run (900kv_noprop vs 900kv_10inch).

Worth re-running on CI hardware where the suite is green at baseline.