fix: preserve plus signs in param flow rules

[hutiefang76]

Describe what this PR does / why we need it

When setting hotspot parameter flow rules through setParamFlowRules, values containing a literal plus sign are currently decoded twice. The HTTP command layer already decodes request parameters before they reach CommandRequest, so decoding data again changes + into a space and alters the configured hotspot item value.

Does this pull request fix one issue?

Fixes #3505

Describe how you did it

Removed the extra URLDecoder.decode(...) call from ModifyParamFlowRulesCommandHandler and added a regression test that submits already-decoded rule JSON with a hotspot item value of a+b.

Describe how to verify it

JAVA_HOME=$(/usr/libexec/java_home -v 17) mvn -pl sentinel-extension/sentinel-parameter-flow-control -am -Dtest=ModifyParamFlowRulesCommandHandlerTest -Dsurefire.failIfNoSpecifiedTests=false test
JAVA_HOME=$(/usr/libexec/java_home -v 17) mvn -pl sentinel-extension/sentinel-parameter-flow-control -am -Dsurefire.failIfNoSpecifiedTests=false test

[CLAassistant]

All committers have signed the CLA.

[oss-sentinel-ai]

Summary

LGTM. Both bundled transports (simple-http HttpEventTask and netty-http HttpServerHandler via QueryStringDecoder) already URL-decode request parameters, so the handler-level decode was double-decoding and corrupting + in hot-param values. Removing it fixes the issue, and the test covers it.

Cross-handler Note

ModifyRulesCommandHandler (flow rules, sentinel-transport-common) still applies the same handler-level URLDecoder.decode and likely has the same double-decode behavior — worth a follow-up PR if you are interested.

---

Automated review by github-manager-bot