fix: clamp over-limit temp basal instead of rejecting with invalidSetting

[Sjoerd-Bo3]

⚠️ DRAFT — untested. Authored on Windows without Xcode; not compiled, not run on a pod. Needs a local build + on-pod check before merge.

Refs #83

Context (root cause is upstream of this change)

Field reports trace every configuration(OmniPumpManagerError.invalidSetting) loop failure to one guard in enactTempBasal:

guard unitsPerHour <= state.maxBasalRateUnitsPerHour else {
    completion(.configuration(OmniPumpManagerError.invalidSetting))
    return
}

Analysis of two users' logs: state.maxBasalRateUnitsPerHour was a stable 2.0 U/hr, while oref's profile-derived maxSafeBasal was 3.0 (= 3× scheduled basal), so every request of 2.05–3.0 U/hr was rejected. The rejection aborts the whole loop cycle before the SMB, so a single above-limit request stops all automated delivery (one user: ~6.5h overnight, no insulin). On a fresh OmnipodKit PM the limit starts at the Pod.maximumBasalUnitsPerHour = 30 default (high rates succeed) until the first syncDeliveryLimits writes the user's lower Trio Max Basal Rate — after which it's enforced.

The real cause is a Trio-side settings mismatch (the Max Basal Rate delivery limit synced to the pump is below oref's maxSafeBasal), which was harmless under OmniBLE/OmniKit because neither enforced the limit in enactTempBasal. That belongs on the Trio side (bind/validate the two, and re-sync) — see nightscout/Trio#1216. This PR only makes the driver non-fatal and diagnosable.

Changes

1. Clamp instead of reject. min(unitsPerHour, state.maxBasalRateUnitsPerHour) → basal is delivered at the configured cap and the loop proceeds to the SMB, instead of aborting.
2. Log on clamp — requested rate vs stored limit, so a stale/incorrect limit is visible instead of silently throttling.
3. Log in syncDeliveryLimits — the value written (and the reject path). This was the missing trace: the limit is enforced but was never logged, so there was no record of when/what set it.

Open question for maintainers

If the guard is intended as a hard safety limit, the alternative is to keep it but (a) not let it abort the loop / block the SMB, and (b) fix the Trio-side mismatch so oref never requests above the synced limit. Happy to adjust to whichever direction the driver/Trio teams prefer.

Testing

• Builds in Xcode
• Above-limit temp basal is delivered at the cap (not rejected) and the SMB still enacts
• syncDeliveryLimits logs the written limit
• Normal in-range temp basals unchanged