Correctly handle dosing & pump events on discard (Loop issue #2382)

[itsmojo]

• Invoke new PodComms handleDiscardedPodDosing() func from forgetPod()
• Move reworked handleCancelDosing() from PodCommsSession to PodState
• Add workaround for old pod sims that don't report a suspended pod on fault

[marionbarker]

Test

Summary:

• ✅ All test cases succeeded.

Test Details

Configuration for rPi pod simulator

• The version of the LoopKit/pod code used for the rPi must be updated to commit ec13f46 or later
  • The behavior of the simulator before that commit did not return a message consistent with the pod delivery being suspended when a fault was inserted by the front end

Configuration for Loop Test Phone

• iPhone SE 3rd gen running iOS 26.1
• begin with LoopWorkspace branch update_dev_to_3.9.4 with OmniBLE commit d8375ebf
• update the OmniBLE branch to discard-pod-fixes, commit 4ae3610
• update Loop and LoopKit branch to pretty-print-pump-events branch (found in loopandlearn username) because that makes the events so much easier to read

Test Various States

As was reported in Loop Issue 2382: OmniXXX Pump Manager does not properly handle a Discard event

• With the code before this PR, a discard event does not provide the suspended state or update any dosing actions that might have been in progress
• With the code in this PR, confirm that the indicated actions do return the correct information to the Pump Manager as seen in the Loop Pump Event record.

List of States Tested

For each test, discard the pod and confirm the proper reporting. The ✅ indicates the test was successfully completed. The screenshots were saved for double-checking and display upon request, but the confirmation was done in real time. Only one set of screenshots is posted below.

1. ✅ discard while pod is delivering scheduled basal (screenshot at 11:17)
2. ✅ discard while pod is delivering temp basal that was automatically started (screenshots at 13:57)
3. ✅ discard while pod is delivering temp basal that was manually started (screenshots at 14:00)
4. ✅ discard while pod is bolusing that was automatically started (screenshots at 14:12)
5. ✅ discard while pod is bolusing that was manually started (screenshots at 14:15)
6. ✅ discard while pod is suspended, suspend at 14:28, interrupt rPi, discard at 14:31
7. ✅ discard because of a fault but after the fault is detected by the Pump Manager (screenshots at 14:35 through 14:41, after next pair)
   • note that the discard has no effect because the pod fault is already detected and suspend is already reported
   • for this case, do it while a manual bolus is in progress
     • start 2 U bolus at 14:35, trigger fault at 14:35:50, rPi status check at 14:36:26, Loop announces fault, ^C the rPi, say OK and discard at 14:36

Note: the case where the fault happened but the Pump Manager did not communicate with the pump cannot be distinguished from the first 6 test cases, so was not tested

[marionbarker]

I think the modification to OmniBLE/OmnipodCommon/MessageBlocks/DetailedStatus.swift should be reverted.

Approve the rest based on test.

[marionbarker]

I remove my request to revert OmniBLE/OmnipodCommon/MessageBlocks/DetailedStatus.swift.

• The modification to that file has no effect on the code, provided the correct message is returned from the simulated (or real) pod
• It has benefit to developers to keep it in when working with others who may not have their simulator up to date
• The code was thoroughly tested with this version