[ISSUE #7981] Fix dynamic match cache eligibility - #7990

Reviewed commit e7e1e83.

The candidate-set eligibility check is a sound conservative fix for #7981: a URI-only generic match is no longer cached when another enabled candidate depends on request headers. Applying the same guard to selector/rule and positive/negative cache writes is consistent. I found no blocking regression in the validation performed.

Validation:

• Ran ./mvnw -pl shenyu-plugin/shenyu-plugin-base -am test -Drat.skip=true -Djacoco.skip=true: BUILD SUCCESS, including all 299 shenyu-plugin-base tests and Checkstyle.
• Re-ran the original in-process reproduction: a VIP request correctly selects the more specific selector after an ordinary request; the dynamic selector negative-cache scenario also behaves correctly.

Two non-blocking suggestions:

1. Add assertions that URI-only candidate sets still populate/reuse the match cache, and that a disabled header-based candidate does not prevent caching. The new tests cover correct dynamic matching but do not protect these eligibility boundaries.
2. Document the deliberate performance tradeoff: one enabled dynamic candidate disables final-result caching for the whole candidate set. This is preferable to incorrect routing, but mixed configurations may perform more matching work.

#7976 and #7978 remain separate pre-existing issues and are not regressions introduced here.

Review limitation: independent reviewer agents could not start because of a service-side model compatibility error. This is a comment review, not a formal approval. No GitHub CI check results were available when reviewed.

This is the more correct of the two open fixes, but it duplicates #7984 - please consolidate

Same root cause as #7977/#7981, and there are now two PRs touching the same four call sites in AbstractShenyuPlugin:

Your new test selectorCacheShouldNotShadowDynamicCandidate demonstrates something #7984 does not fix: the positive entry is equally unsound. Request 1 (X-Tenant: b) uniquely matches generic, that result is cached under the path, and request 2 (X-Tenant: a) then gets generic from the cache and never evaluates tenant. So caching a positive match is only safe when the candidate set is path-determined too - which is what canCacheSelectorMatch adds. That makes this PR the stronger fix, and it means merging #7984 alone would leave the bug half-open.

Two things to add before this is equivalent-or-better than #7984, then one of the two PRs should be closed:

1. matchRestful. isPathDeterminedSelectorSet / isPathDeterminedRuleSet in #7984 also reject a candidate when getMatchRestful() is true. A restful selector's URI condition is a template, so it matches many paths; caching by exact path is a different (narrower) key than what was evaluated. Include it for the same reason.
2. Selector type scoping. filterSelector only evaluates conditions for SelectorTypeEnum.CUSTOM_FLOW; for other types it returns true regardless of the condition list. Your canCacheSelectorMatch inspects every enabled selector's conditions, so a full-flow selector that happens to carry a header condition (never evaluated) disables caching for the whole plugin. Harmless but pessimistic; scoping to CUSTOM_FLOW keeps the previous hit rate.

Also worth a comment in hasOnlyUriConditions about the empty-condition case: CollectionUtils.isNotEmpty(conditions) returns false, which disables caching. That matches filterSelector behaviour for CUSTOM_FLOW (empty conditions never match), but it reads like an oversight.

CI: no checks reported on this head yet, so this review is based on the diff only.