[BUG] Renaming an MCP rule tool leaves the previous tool name registered #8025

Is there an existing issue for this?

• I have searched the existing issues.

Current Behavior

An MCP rule can define its effective tool name in handle.name, falling back to RuleData.name. On update, handlerRule overwrites rules[id] with the new snapshot before registering the new name. ShenyuMcpServerManager.addTool only removes an existing tool with that new name. The old name remains registered with its old callback/request configuration. Later removeRule parses only the current handle/name, so deletion can leave the orphaned old tool behind.

Expected Behavior

A rule has one current registration identity. When its effective name or server binding changes, remove the previous registration before replacing it, and ensure subsequent disable/delete removes all registrations owned by that rule. Normal same-name updates should continue replacing the callback.

Steps To Reproduce

1. Register an enabled rule R with handle.name=old-tool and verify it is listed.
2. Update the same rule ID with handle.name=new-tool, leaving the server unchanged.
3. The handler adds new-tool without calling removeTool for old-tool; both names can remain registered.
4. Delete R. Current removeRule removes new-tool, leaving old-tool orphaned.
5. Also cover fallback names: blank handle.name with a change to RuleData.name.

Environment

• ShenYu master / 2.7.2-SNAPSHOT, commit 34f2ed036747936a5e28aea2c94cd9b3cddcce47.
• Source-inspection report. The reporting environment has no available JDK; no Maven/JUnit, live backend or Redis reproduction is claimed.
• Existing runtime behavior; unrelated to proposed plugin orchestration.

Debug logs

No runtime logs captured. Code evidence follows.

Code evidence

• Old snapshot overwritten before effective-name registration
• addTool removes only the incoming name
• UPDATE sync carries current rule data

Suggested fix direction

Track the applied registration identity (rule ID, effective server path and effective name) separately from the newest desired definition. Revoke the old identity on rename/move, then register the replacement with defined failure recovery. Do not infer old identity from the incoming payload after overwriting it.

Acceptance criteria

• Custom-name rename and fallback rule-name rename leave only the current name in the actual SDK server.
• Old names cannot be newly invoked; deleting/disabling the renamed rule leaves no orphan.
• Cover same-name updates, duplicate events and selector/server moves without removing unrelated tools.
• Registration/removal failures leave observable recoverable state.

Related work and scope

Related to closed #6473, which corrected choosing the custom name during deletion. This report concerns the distinct old-name -> new-name update transition; current deletion of the new name does not clean the old registration. Suggested priority: P2.