Apply local upper and lower limits

Limits are mandatory; min(U_LIMIT, max(ADV_UTO, REMOTE_UTO, L_LIMIT)) is the RECOMMENDED scheme.

• Hosts MUST impose upper and lower limits on accepted and used user timeouts. With ENABLED and CHANGEABLE true, hosts SHOULD adjust the local timeout; RFC 5482 gives a RECOMMENDED limiting formula, not the only possible policy.
• The lower limit L_LIMIT MUST be larger than the connection’s current RTO. When following the recommended scheme, L_LIMIT SHOULD be at least 100 seconds. “Larger” is strict; equality with the RTO does not satisfy it.
• The valid illustrative configuration uses ADV_UTO = 300, REMOTE_UTO = 600, L_LIMIT = 100, U_LIMIT = 900 and current RTO = 5, all in seconds. max(300,600,100) = 600, then min(900,600) = 600.
• In a separate high-advice fixture, REMOTE_UTO = 1800 with the same 900-second upper limit yields 900. The limit caps the result even though the peer advertised a larger value.
• A different endpoint with an upper limit of 450 can adopt 450 while its peer adopts 900. Endpoints do not necessarily adopt the same user timeout. This is advice, not a binding common deadline.
• Limits MAY be system-wide or more specific and need not be static. Dynamic resource/attack status may affect them. A sender may close or abort at its own discretion; a long advertised value is no guarantee.

Only the RFC’s recommended calculation is modeled. Inputs are finite integer-second fixtures with a consistent lower/upper interval; this helper rejects invalid configurations instead of modeling arbitrary system policy. No application API or TCP implementation is exercised.