fix(plugin-mcp): import Effect-native SDK symbols from /core in the core build

[fdarian]

Summary

@executor-js/plugin-mcp's ./core entry is unusable. Importing from it throws
at module load:

SyntaxError: Export named 'tool' not found in module '.../@executor-js/sdk/dist/index.js'

This reproduces in the published 1.5.28 and 2.0.0 artifacts. To use /core
today I had to patch the installed package;
this PR removes the need for that.

Root cause

Two mcp plugin source files import Effect-native-only symbols from the bare root
"@executor-js/sdk" instead of "@executor-js/sdk/core":

• packages/plugins/mcp/src/sdk/plugin.ts (tool, definePlugin, ToolResult, ToolName, ...)
• packages/plugins/mcp/src/sdk/invoke.ts (ElicitationId, FormElicitation, UrlElicitation)

tsup preserves import specifiers verbatim (no build-time rewrite to /core), so the
bare root import survives into dist/core.js, where it resolves to the promise facade
that lacks those exports. That is why the fix is a source change, not a bundler config
change.

Fix

Import the Effect-native symbols from @executor-js/sdk/core in those two source
files. This matches the existing convention: sibling dual-surface plugins
(onepassword, google, microsoft, openapi) already import definePlugin,
tool, ToolResult, and related Effect-native symbols from @executor-js/sdk/core
in source.

Verification

• Rebuilt the plugin and confirmed the emitted /core chunk now imports the
  symbols from @executor-js/sdk/core, and that no emitted JS in
  packages/plugins/mcp/dist/*.js still imports the bare @executor-js/sdk root.
• typecheck and lint pass for the change.

Before (emitted /core artifact):

} from "@executor-js/sdk";

After:

  definePlugin,
  tool,
  ToolResult,
  ToolName,
} from "@executor-js/sdk/core";

import {
  ElicitationId,
  FormElicitation,
  UrlElicitation,
} from "@executor-js/sdk/core";

Scope

Confirmed unique to plugin-mcp. Most sibling dual-surface plugins already use
the correct @executor-js/sdk/core source imports, so no broader change is
needed.

[RhysSullivan]

thanks, will also get some better CI in place for these + actually useful docs

separating 'executor the platform' from 'executor the product' so it'll be a lot easier to use these sdks without bringing along a bunch of other stuff like toolkits and policies