[BUG] Parameter rule reload loses in-flight counts after a limit change #3667

Issue Description

Type: bug report

Describe what happened

Changing a parameter thread rule's limit during reload can discard counts for requests that are still running. A newly loaded rule then admits a request that its new limit should block.

This remains reproducible on #3657 at 04e791b153fbac95896a25d872a78d174e6b8e64, after its fix for counters shared by initialized rules. It is the manager-side boundary discussed in that review, rather than a regression in that patch.

Describe what you expected to happen

If the new rule set still controls the same resource and parameter index, its thread limit should include requests already in flight. Removing the last rule for an index or the resource should still release its metrics.

How to reproduce it (as minimally and precisely as possible)

1. Load thread-grade rules for one resource, paramIdx = 0, with counts 10, 5 and 7.
2. Keep two real SphU.entry(resource, EntryType.IN, 1, value) entries open for the same value.
3. Call ParamFlowRuleManager.loadRules with a single rule for the same resource/index and count 2.
4. Try a third entry before closing the first two. It is admitted, although two entries are already running at a limit of two.

The reload removes old rules by full value equality. All old rule values are gone, but the replacement still uses the same index. Its counters are initialized lazily, so the initialized-rule check cannot see it while the old rules are cleaned up.

Tell us your environment

macOS arm64, Microsoft OpenJDK 17.0.18; Sentinel 1.8.11-SNAPSHOT with #3657 at the revision above.

Anything else we need to know?

A focused regression uses actual entry/exit callbacks. Two reload cases fail because the extra entry is admitted; six controls pass, including an unchanged survivor, another parameter index, resource removal and no in-flight entries. No compilation errors or skipped cases occurred.

I am working on a small follow-up that lets the manager use the newly loaded rule set when deciding the shared counter's lifetime, while still cleaning up removed rules' own counters. It builds on #3657 and will keep that dependency explicit.

_{Drafted by an AI assistant for @hutiefang76.}