Handle concurrent monitored item resets

[kevinherron]

Summary

• return per-item Bad_InvalidState results when monitored item server state disappears during SetMonitoringMode or DeleteMonitoredItems request construction
• continue processing valid items while preserving caller-order result alignment
• document the non-throwing behavior for items without server state
• add deterministic regression coverage for both reset timing windows, never-created items, and the sibling deletion race

Root cause

A monitored item's syncState and serverState are separate volatile fields. Session reactivation or concurrent deletion can clear them between setMonitoringMode() validation and the later monitored-item ID lookup, causing either IllegalArgumentException or NoSuchElementException. The deletion path used the same throwing ID lookup pattern.

Impact

Callers now receive a Bad_InvalidState service result for each affected item instead of a race-dependent exception. Valid items in the same request are still sent to the server and their results remain aligned with the original input list.

Validation

• mise exec -- mvn -q spotless:apply
• mise exec -- mvn -q -pl opc-ua-sdk/integration-tests -am test -Dtest=OpcUaMonitoredItemTest -Dsurefire.failIfNoSpecifiedTests=false
• mise exec -- mvn -q clean compile

Fixes #1814