fix(scene): route PinK MCP operations through hierarchy

[bofeng-song]

Related issue: https://zentao.sud.center/index.php?m=bug&f=view&bugID=974

Summary

• Route MCP scene requests to the SceneInstance owned by PinK Hierarchy.
• Keep the CLI scene worker running only for Scene WebView bootstrap services such as i18n, asset, and engine RPC.
• Add authority-routing tests and document the temporary bridge and the required native PinK integration.

Problem

The cocos-code utility process and the Hierarchy Scene WebView run in different processes. The CLI worker creates its own cc.Scene, so opening the same .scene file in both processes does not share unsaved changes, Undo state, or selection state. As a result, MCP could query or modify a stale scene copy while Hierarchy showed a different scene.

Why this approach

MCP requests now use a single authority entry point. In PinK, that entry point forwards Editor, Node, Component, and Prefab operations to the SceneInstance behind Hierarchy. This makes MCP edits visible in Hierarchy immediately and preserves the IDE Undo flow without attempting to synchronize two in-memory scenes.

The worker is intentionally still started. Scene WebView initialization depends on its RPC services; making it a no-op breaks i18n and engine bootstrap. The worker is no longer allowed to be a fallback authority for MCP operations in the IDE.

scene-save returns no data after a successful command instead of fabricating partial asset metadata, which keeps the MCP result contract valid.

PinK follow-up

This change includes a temporary project-scoped named-pipe adapter to validate the routing end to end. PinK should replace it with an internal project-scoped authority channel:

1. The cocos-code utility process injects bindIdeSceneAuthorityRpc() during scene initialization.
2. PinK main process routes each request to the matching project/window.
3. The Hierarchy extension resolves the active or sole opened SceneInstance and forwards the request to the Scene WebView.
4. The native channel validates that the target SceneInstance is still open and never falls back to the CLI worker.

The worker must remain available for Scene WebView infrastructure after this native channel replaces the temporary bridge.

Validation

• npx tsc -b
• npm test -- --runInBand src/core/scene/test/scene-authority-request.test.ts src/core/scene/test/lib-scene-authority.test.ts --detectOpenHandles
• git diff --check

[bofeng-song]

#873
fixed the issue.