Fix OperationLimits to apply min(client, server) logic per documentation

[Copilot]

Proposed changes

FetchOperationLimitsAsync was unconditionally applying server operation limits, ignoring client configuration. Per documentation in ApplicationConfiguration.cs: "Values not equal to zero are overwritten with smaller values set by the server."

Changes

• Session constructor: Initialize OperationLimits from ClientConfiguration.OperationLimits
• FetchOperationLimitsAsync: Apply min(client, server) logic via new ApplyOperationLimit helper
  • If client limit is 0 (unconfigured), use server value
  • If server limit is 0, use client value
  • Otherwise, use minimum of both
• Tests: Added scenarios for client-smaller, server-smaller, and zero-value cases
• Test infrastructure: Made SessionMock constructor internal for test access

Behavior

// Client sets max limits
ClientConfiguration.OperationLimits.MaxNodesPerRead = 500;

// Server reports higher limit
await session.FetchOperationLimitsAsync();

// Result: min(500, 1000) = 500 (respects client limit)
Assert.That(session.OperationLimits.MaxNodesPerRead, Is.EqualTo(500));

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• Enhancement (non-breaking change which adds functionality)
• Test enhancement (non-breaking change to increase test coverage)
• Breaking change (fix or feature that would cause existing functionality to not work as expected, requires version increase of Nuget packages)
• Documentation Update (if none of the other choices apply)

Checklist

• I have read the CONTRIBUTING doc.
• I have signed the CLA.
• I ran tests locally with my changes, all passed.
• I fixed all failing tests in the CI pipelines.
• I fixed all introduced issues with CodeQL and LGTM.
• I have added tests that prove my fix is effective or that my feature works and increased code coverage.
• I have added necessary documentation (if appropriate).
• Any dependent changes have been merged and published in downstream modules.

Further comments

Backward compatible: existing behavior preserved when client limits are 0 (default). Line length formatting adjustments required for Roslynator compliance.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>OperationLimits remark does not match FetchOperationLimitsAsync functionality</issue_title>
<issue_description>### Type of issue

• Bug
• Enhancement
• Compliance
• Question
• Help wanted

Current Behavior

With the changes in #3303 FetchOperationLimitsAsync in Libraries/Opc.Ua.Client/Session/Session.cs always sets the operation limits to those of the server.

Expected Behavior

Prior to the changes in #3303 it seems that operation limits were set to the ones of the client, except if the value was 0 or the respective server value was smaller through FetchOperationLimitsAsync in Libraries/Opc.Ua.Client/Session/Session.cs. This seems to almost follows the remark in Stack/Opc.Ua.Core/Schema/ApplicationConfiguration.cs": Values not equal to zero are overwritten with smaller values set by the server." I expect either the prior functionality or the one described in the remark.

Steps To Reproduce

1. Open up Libraries/Opc.Ua.Client/Session/Session.cs before and after Refactor client state persistence and add more tests #3303
2. Open up Stack/Opc.Ua.Core/Schema/ApplicationConfiguration.cs and read the remark on OperationLimits

Environment

Anything else?

No response</issue_description>

<agent_instructions>Please make so the Client sets the OperationLimits for the Server or uses the ones configured if those are smaller</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes OperationLimits remark does not match FetchOperationLimitsAsync functionality #3501

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}