fix(plugin-sdk): scaffold one SDK specifier, not two

[lovepixel-git]

Refs #384. The report is about @instatic/plugin-sdk not resolving. Chasing it down turned up something a bit worse: the scaffold emits two different specifiers, and one of them resolves nowhere.

Reproduced

instatic-plugin init ce-plugin --kind content-editor

produces exactly two source files:

ce-plugin/instatic-plugin.config.ts:1:  import { definePlugin, permissions } from '@core/plugin-sdk'
ce-plugin/server/index.ts:1:            import type { ServerPluginModule } from '@instatic/plugin-sdk'

@core/plugin-sdk resolves through this repo's tsconfig.json paths. @instatic/plugin-sdk resolves nowhere: node_modules/@instatic does not exist, package.json is named instatic with no exports map, and there is no @instatic/* path alias. So one of the two files in a fresh content-editor plugin cannot resolve its import even inside the monorepo.

init.ts emits @core/plugin-sdk in three templates and @instatic/plugin-sdk in exactly one, so this reads as an oversight rather than intent.

Change

Two things, both small.

The scaffold now emits one specifier. serverEntryTemplate matches its sibling, so a scaffolded content-editor plugin resolves in-tree today.

The docs get the constraint stated in the "Local dev with hot sync" section, which is already the place that handles out-of-tree setup for INSTATIC_UPLOADS_DIR. Neither specifier is a published package, so a plugin repo outside an Instatic checkout has to point at the SDK source; the reporter's env-var indirection module is a reasonable shape for that.

One thing that is yours to decide

I did not touch the three @instatic/plugin-sdk examples in the docs (lines ~970, ~1030, ~1064) or the SDK builder docstrings, because they are only wrong until you publish the package, and right the moment you do. Rewriting them to @core/plugin-sdk would make them accurate today and wrong later.

The same tension applies to the scaffold fix, and it is why I framed it as consistency rather than as choosing a specifier: two files should not disagree, and matching the one that resolves is the option that works now. If you would rather publish @instatic/plugin-sdk and move the other three templates onto it, that inverts this diff and I am glad to send that instead — it is the nicer end state for anyone distributing a plugin, since it also makes bun test work on plugin sources without a full CMS checkout.

Verification

• Scaffolded before and after; the generated plugin now uses one specifier in both files
• bun run lint clean
• bunx tsc -b exit 0
• 171 tests across src/__tests__/plugins pass