fix: route cloud debug plugins to runtime owner - #779

Summary

Remote debug plugins are now identified using the persisted installation runtime type instead of inferring their runtime type from the plugin author's format.

Background

Historically, RemotePluginRuntime.Identity() replaced the plugin manifest author with the tenant UUID:

<tenant-uuid>/<plugin-name>:<version>@<checksum>

PluginUniqueIdentifier.RemoteLike() therefore used “the author is a UUID” as an implicit marker for remote debug plugins.
This behavior changed in #731 while fixing #730. To keep plugin_id consistent between runtime listings and installation records, remote debug identities started preserving the manifest author:

langgenius/openai:<version>@<checksum>

Preserving the manifest author was the correct fix for plugin identity consistency, but it invalidated the UUID-based remote runtime detection.
#761 later restored cross-node redirection for remote debug plugins, but continued to gate the redirect logic with:

identity.RemoteLike()

For identities such as langgenius/openai, RemoteLike() returns false.

In a multi-node serverless deployment, a remote debug runtime only exists on the node that owns the debugging connection. Requests routed to that node succeed, while requests routed to another replica are treated as normal serverless invocations. Since a newly debugged plugin does not have a serverless runtime, those requests fail with a runtime/node-not-found error.

This made the issue appear intermittent and dependent on load-balancer routing.

Type of Change

• Bug fix
• New feature
• Refactor
• Performance improvement
• Other

Essential Checklist

Testing

• I have tested the changes locally and confirmed they work as expected
• I have added unit tests where necessary and they pass successfully

Bug Fix (if applicable)

• I have used GitHub syntax to close the related issue (e.g., Fixes #123 or Closes #123)

Additional Information

Please provide any additional context that would help reviewers understand the changes.