fix: parse Character exception items as boxed character values

[hutiefang76]

Describe what this PR does / why we need it

ParamFlowItem.newItem boxes a char and records java.lang.Character, but ParamFlowRuleUtil only recognizes the primitive char class name. The parsed exception item gets a String key and does not match a runtime Character argument.

Does this pull request fix one issue?

Fixes #3656.

Describe how you did it

Recognize Character.class.getName() alongside primitive char, matching the existing primitive/wrapper pairs. Add real newItem parsing and thread-checker threshold regressions.

Describe how to verify it

JDK 17: ParamFlowRuleUtilTest and ParamFlowCheckerTest passed 11 tests independently on this PR branch. Against the old parser, the Character-key assertion fails and the checker cannot find the item threshold. Java 8 execution was blocked by the existing compiler/toolchain bytecode mismatch; no Java 8 pass is claimed.

mvn -q -pl sentinel-extension/sentinel-parameter-flow-control -am -Dtest=ParamFlowRuleUtilTest,ParamFlowCheckerTest -Dsurefire.failIfNoSpecifiedTests=false test

Special notes for reviews

AI assistance: implementation and initial review used DeepSeek; Codex coordinated final review and verification.

[konlue]

Verified locally on 1.8: the one-line change plus the new tests pass (module suite green), and reverting ParamFlowRuleUtil.java alone turns testParseHotParamItemsWithCharacterWrapper red (The parsed key should be a boxed Character) and the checker test errors on unboxing a null lookup — so the tests genuinely pin the bug.

The root cause matches the diff exactly: ParamFlowItem.newItem(char, n) boxes the value and records java.lang.Character as the class type, while parseItemValue only matched the primitive name (char), so an exception item built through the public API ended up keyed by a String and never matched the boxed Character argument at check time. The existing test never caught this because it constructs the item manually via setClassType(char.class.getName()), bypassing the real path — the new test going through newItem + fillExceptionFlowItems is the right way to pin it.

Two tiny notes, both non-blocking:

1. Style: char.class.toString() could become char.class.getName() (same value, "char") for consistency with the other seven branches.
2. Pre-existing, just to confirm intent: an empty-string value still returns null from the char branch (array.length > 0 ? array[0] : null), which puts a null key into the parsed map. Harmless in practice since null args are skipped at check time, but worth being aware of.

Nice find — this is exactly the kind of mismatch that only shows up through the real construction path.

[hutiefang76]

Thanks for checking the public construction path. Yes, the empty-string behavior is unchanged: it still returns null. This patch only adds the boxed Character class name to the existing char branch; it does not change empty-value handling.