feat: align router rule delivery and management chain

[xiaobaicai66695]

Please provide a description of this PR:

Background

Closes #1523.

Dubbo Admin could model several traffic rules, but the complete delivery chain was inconsistent across the Console API, configuration-center storage, watcher decoding, frontend editing, and dubbo-go runtime consumption. In particular, rule names and ZooKeeper paths could diverge, Condition YAML could lose fields after switching tabs, and Affinity/Script rules did not have a complete management path.

What this PR changes

Rule delivery and configuration-center contract

• Adds a shared external YAML codec and validation path for Condition v3.0/v3.1, Tag, Affinity, Script, and Dynamic Config rules instead of exposing internal protobuf YAML directly.
• Keeps Condition v3.0 string conditions and v3.1 structured from/to/weight conditions version-specific and round-trip safe.
• Adds Script route protobuf/resource types and wires Script and Affinity resources into the resource, versioning, watcher, and governor flows.
• Standardizes ZooKeeper writes, reads, updates, and deletes on /dubbo/config/dubbo/<rule-name>, creates missing parent nodes, and keeps legacy locations read-only for compatibility.
• Uses the configured Config Center address for rule delivery, with registry address fallback for compatibility, and aligns Nacos and ZooKeeper on the same external YAML contract.
• Makes Service Argument Route create/update an upsert so its first save no longer depends on a pre-existing resource.

Console API

• Adds search/detail/create/update/delete endpoints for Affinity and Script rules.
• Adds typed Condition input conversion so v3.0 and v3.1 request bodies are decoded without losing their version-specific condition shape.
• Validates rule names, suffixes, scope, keys, script type/content, and route content before calling the governor.
• Preserves mutation metadata and version-history behavior for the new rule types.

Frontend

• Adds Affinity and Script list/editor routes using shared router-rule list and YAML editor components.
• Fixes the traffic menu state so nested dynamic-router pages expand and select consistently; this is navigation grouping only, not a runtime parent/child relationship.
• Fixes Condition form/YAML equivalence: v3.1 structured conditions are visible and editable in the form, while v3.0 continues to use string conditions.
• Reloads complete Condition details when tab state contains only a partial draft and stops form initialization from publishing an incomplete { enabled, key, runtime, scope } object.
• Preserves configVersion, priority, force, conditions, and the remaining backend fields across detail, form, YAML, and save round trips.
• Aligns Tag rule names generated by both form and YAML creation with the runtime node name.

Problems fixed

Problem	Root cause	Resolution
Deleting a previously created rule could fail with zk: node does not exist	Create/read/delete used different rule-name or legacy path derivations	All new operations use the same standard node path and update can create a missing standard node
Saved Condition YAML later showed only enabled/key/runtime/scope	A partial shared tab object was treated as complete and initialization overwrote the full detail	Detect incomplete shared state, reload backend detail, and preserve the complete rule object
Condition YAML contained conditions, but the form did not	The form only understood v3.0 strings and had no v3.1 structured editor	Add version-aware models and structured v3.1 form rendering/editing
Condition YAML editing silently forced v3.0	The YAML update path overwrote configVersion	Submit the version and condition shape provided by the rule
Affinity and Script lacked a complete Admin chain	Resource/API/watcher/frontend wiring was incomplete	Add resource types, codecs, validation, CRUD APIs, watcher/governor integration, routes, and UI
First Service Argument Route save could fail	The service path only updated an existing resource	Use create-or-update semantics

End-to-end verification

The local reproduction harness verifies the full behavior chain, not only receipt of a ZooKeeper event:

Admin UI / Console API
  -> /dubbo/config/dubbo/<rule-name>
  -> dubbo-go listener / router / configurator
  -> actual provider calls
  -> ASSERTION_PASS and process exit code 0

The harness and evidence are intentionally kept outside this PR under quickstart-demo/e2e/admin-router-rule-chain; they are local reproduction artifacts and are not tracked by dubbo-admin.

Scenario	Isolated service	Result
Condition v3.0 / v3.1	Greeter, group demo, providers 20000/20001	Manually verified hot updates for both versions; each version routed continuous calls only to Hangzhou 20000, and disabling/deleting the rule restored unrestricted provider selection
Tag primary	GreeterTag, group tag	8/8 calls routed to Hangzhou 20100; Admin detail, standard ZK node, consumer assertion, and provider logs all passed
Tag secondary update	Same rule	8/8 calls switched to Shanghai 20101
Script primary	GreeterScript, group script	8/8 calls routed to Hangzhou 20200 through actual JavaScript invoker filtering
Script secondary update	Same rule	8/8 calls switched to Shanghai 20201
Affinity primary	GreeterAffinity, group affinity	Hangzhou consumer application: 8/8 calls to the matching Hangzhou provider 20300
Affinity secondary	Same rule	Shanghai consumer application: 8/8 calls to the matching Shanghai provider 20301
Dynamic Config control	GreeterDynamic, group dynamic	consistenthashing with identical arguments kept all 8 calls on one provider; Admin response, standard ZK node, consumer assertion, and provider logs passed

The newer Dynamic Config roundrobin variant has not produced a final successful report yet, so it is deliberately not claimed as passed here. Dynamic Config runtime parsing/matching also depends on apache/dubbo-go#3660 (background: apache/dubbo-go#3661).

Automated tests

• go test ./... — passed.
• yarn test — passed: 9 test files, 18 tests.
• ESLint on all changed TS/Vue files — passed with 0 errors (existing unused-variable warnings remain in legacy Tag files).
• yarn vite build — passed.
• git diff --check upstream/develop...HEAD — passed.

New regression coverage includes external YAML codec round trips and validation, Console request/response contracts, Service Argument Route upsert behavior, ZooKeeper path/config-center selection, Condition v3.1 form/YAML round trips and incomplete-state reload, Tag rule naming, and nested menu state.

yarn type-check and repository-wide yarn lint still report pre-existing baseline errors in unchanged Home, Resource/Grafana, test placeholder, and legacy traffic pages. The changed-file ESLint run and production Vite build complete successfully.

To help us figure out who should review this PR, please put an X in all the areas that this PR affects.

• Docs
• Installation
• User Experience
• Dubboctl
• Console
• Core Component

Please check any characteristics that apply to this pull request.

• Adds or changes Console API behavior
• Adds frontend traffic-rule management
• Changes configuration-center serialization and node handling
• Includes backend and frontend regression tests

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud