Fix MCP named tool methods failing with apply error in GatekeeperLoopback

[dreh23]

What does this change?

In GatekeeperLoopback (packages/workshop-backend/src/overseer.ts), the proxy wrapping the gatekeeper session RpcStub used Reflect.get(target, prop, target) in its get trap.

When an agent in executeCode calls a dynamically-installed MCP tool method (e.g. env.MY_MCP.myToolName({...})), that method name was attached at runtime to the session prototype by installToolMethods(), but is not in workerd's statically-known RPC surface for the base stub type.

Because the property is not in the static surface, Reflect.get(rpcStub, prop) returns an RpcProperty pipeline sub-stub. Calling that sub-stub as a function causes workerd to dispatch an RPC method named "apply" to the remote receiver (McpSessionImpl), which does not implement it, throwing:

TypeError: The RPC receiver does not implement the method "apply"

This patch changes the get trap to return a wrapper function for string property accesses:

return function(this: unknown, ...args: unknown[]) {
  return (target as Record<string, (...a: unknown[]) => unknown>)[prop as string](...args);
};

This causes workerd to dispatch target[prop](...args) as a direct named RPC method call to the remote session, where the dynamically-installed method on the prototype chain handles it. Symbols and "then" continue to pass through directly.

Why is this obviously correct and trivially verifiable?

1. Self-contained: It changes only the get handler inside GatekeeperLoopback (17 lines changed).
2. Preserves standard RPC behavior: Symbols (like Symbol.dispose) and "then" pass through via Reflect.get(target, prop, target), maintaining lifecycle and Promise resolution invariants.
3. No new surface or dependencies: For statically-known methods, calling target[prop](...args) on the stub dispatches the same RPC call as before. For dynamically-installed prototype methods (which previously threw TypeError), it now dispatches the intended method call.

Checklist

Checking every item does not guarantee acceptance. Maintainers determine whether
a pull request meets the contribution policy.

• This is a small, concrete change; it is not a feature, refactor, or low-value cleanup.
• I understand that maintainers decide whether the change is obviously correct and trivially verifiable.
• I have read and followed the contribution guidelines.

---

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[dreh23]

I have read the CLA Document and I hereby sign the CLA

[dreh23]

recheck

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.