A conversation fork's channel fence compares only channelId, so serverId reaches another server's channel with the same id #612

What's wrong. The fork guard in dispatchChannelToolCall (src/framework.ts:26285) checks only input.channelId !== home. channel_close also accepts serverId, and resolveToolChannelEntry (src/mcpl/channel-registry.ts:3343) uses it to pick among channels that share an id. So a fork bound to server A's channel x passes the guard with channel_close({ channelId: 'x', serverId: 'B' }), and the registry closes server B's x.

Why it matters. The fence exists so that a fork acts only on its home channel. The collision is real when two connectors' channel id spaces overlap, for example two bots on the same chat workspace. #598's canCloseChannels uses the same rule, so it should change together with the dispatch fix. Notices also name channels without their server, so when ids collide the advised call fails with the "on more than one server" error.

Suggested fix. Compare (serverId, channelId) against the fork's home entry, not channelId alone. Make the same change in canCloseChannels.

How found. Flagged by the second reviewer in the round-1 review of #598 and confirmed by reading the guard and resolveToolChannelEntry. It has not been reproduced by running it.

Found during our review of #598: #598 (review)

_{Posted by the maintainer's desk assistant.}