[BUG] connlimit breaks localhost connections since 6.17.13

[Michal Slabihoudek <michal.slabihoudek@gooddata.com>]

Hello netfilter maintainers, 
I would like to report a regression related to the connlimit match.

 Kernel versions:
• 6.17.12: working
• 6.17.13: broken
• 6.18.3: still broken

 Distribution:
• CentOS Stream 9

 Netfilter component:
• connlimit (iptables)

 Description:
Applying an iptables rule using the connlimit module causes TCP connections
to be dropped (client observes connection timeout), even though the rule
action is LOG and not DROP/REJECT.
 This happens specifically when connecting from localhost to a non-localhost
IP address (i.e. not in 127.0.0.0/8). The first connection succeeds, but
subsequent connections immediately time out.
 Removing the iptables rule with the connlimit match fully resolves the issue.

 Expected behavior:
• connlimit should only match and log packets
• connection handling should remain unaffected when using -j LOG

 Actual behavior:
• connections are silently dropped
• client experiences TCP connection timeout

 Reproducer:
Target port: TCP 443

 iptables rule used (for custom logging only):
 ```
iptables -I INPUT -p tcp --dport 443 \
  --tcp-flags FIN,SYN,RST,ACK SYN \
  -m connlimit --connlimit-above 500 \
  --connlimit-mask 32 --connlimit-saddr \
  -j LOG --log-prefix "IPT-443: "
 ```

iptables ruleset:
 ```
Chain INPUT (policy ACCEPT)
num  pkts bytes target prot opt in out source      destination
1      0     0 LOG    tcp  --  *  *   0.0.0.0/0   0.0.0.0/0
       tcp dpt:443 flags:0x17/0x02 #conn src/32 > 500
       LOG flags 0 level 4 prefix "IPT-443: "
 ```

Test case:
 First connection from localhost to instance IP (X.X.X.X):
 ```
curl -I -L -k -m 3 https://X.X.X.X
-> HTTP/2 200 OK
 ```
Immediate second connection:
 ```
curl -I -L -k -m 3 https://X.X.X.X
-> curl: (28) Connection timed out after 3001 milliseconds
 ```

Without the iptables rule applied, repeated connections succeed without
any issue.
 Notes:
• This looks like a regression introduced in 6.17.13
• The behavior resembles an implicit drop, despite using LOG only
• Regression might be introduced by https://github.com/torvalds/linux/commit/69894e5b4c5e28cda5f32af33d4a92b7a4b93b0e

 Please let me know if further debugging data (conntrack state, traces,or kernel logs) would be helpful.

Best regards.