P6.2-C: make MMS reconnect bounded, staged, and recovery-aware

[masarray]

P6.2-C Smart Reconnect

Stacked on P6.2-B / PR #219. Physical field evidence on 192.168.81.17 showed a real transport-offline event followed by a long recovery stall: smart reconnect started at 10:29:25 but the next successful fast association was not visible until 10:47:44. P6.2-B already removed unsafe automatic full-dynamic mutation, so this PR focuses only on runtime connection lifecycle and recovery pressure.

Corrections

• bound stale-client cleanup to 750 ms so a stuck dispose cannot hold the monitor loop indefinitely;
• bound each fresh ACSE/MMS reconnect attempt to 10 s and expose deterministic retry/backoff timing (1/2/4/8/15/30 s cap);
• treat ACSE/MMS association as recovered immediately, then defer static RCB planning/re-arm back to the normal background pipeline;
• stagger first recovery reads across at most 2 s and apply a temporary 2 s polling floor during a 10 s warm-up instead of bursting all selected points at once;
• give a recovered association a 3 s settle window before static RCB re-arm;
• defer q/t companion reads and health probes during recovery warm-up;
• automatically retry a saved-model initial connection once, addressing the field case where a second manual attempt often succeeds;
• log QUALITY_EVIDENCE when IEC quality is questionable/invalid/reserved, while preserving the IED quality exactly and never forcing Good;
• keep the exact P6.2-B ARIEC engine pin and reporting policy unchanged.

Automated validation

Final head c5cd6e537a31967e55aeba77da7e02f028770976 passed Build ARSAS #1297, Windows installer #283, IO List #283, and SV evidence #419. Full ARSAS regression, portable smoke, and silent installer install/uninstall all passed.

Acceptance

Keep draft/unmerged until physical SIPROTEC retest proves reconnect attempts are bounded/visible, MMS resumes before report re-arm, static reporting re-arms after the settle window, repeated recovery does not stall, and degraded quality remains attributable rather than cosmetically rewritten.

[masarray]

P6.2-C field-evidence + CI record

Field trigger: AA1C1F13R4 / 192.168.81.17 logged transport offline + smart reconnect start at 10:29:25, but no successful reconnect until 10:47:44. Both IEDs use the same Asix 192.168.81.240/24 path, while AA1C1F13R1 remained active, so the app recovery path needed to be bounded independently of any physical-path investigation.

Final P6.2-C head: c5cd6e537a31967e55aeba77da7e02f028770976
P6.2-B engine pin remains unchanged: 249fb130e0e18e7a98e07e8894f24610bdb5642e.

Final CI on this exact head:

• Build ARSAS #1297 (32215310607) — SUCCESS; restore/build/full regression/portable publish+smoke all success.
• Windows installer #283 (32215310572) — SUCCESS; restore/build/test/compile/silent install+uninstall all success.
• IO List #283 (32215310624) — SUCCESS.
• SV evidence #419 (32215310646) — SUCCESS.

Physical acceptance still required. Expected log sequence after a real drop is now explicit per-attempt reconnect -> successful MMS association -> staggered MMS warm-up -> delayed static RCB re-arm. QUALITY_EVIDENCE must be used to distinguish real IED q=questionable/invalid from acquisition/mapping defects; no path forces quality to Good.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.