docs+plugindev: README 同步子进程架构，scaffold 修 entry 与 go.sum 死路

三类问题，都会让新用户第一次上手就走错：

1. README 仍写 plugin.so
   plugin.json 示例的 entry、entry 字段说明、.hmap 包格式三处描述的都是
   已退场的 C ABI 产物。改为 plugin.bin，并补 bundle 模式下
   plugin.bin.<goos>.<goarch> 的命名与安装时挑平台的行为。

2. cmd_init.go 的 entry := "plugin.so"
   scaffold 出来的 plg.json 带着一个已退场的 entry 值。build 实际不看这个
   值（只用它区分 Lua），但跟着模板走会误以为自己在做 C ABI 插件。

3. 生成的项目第一次 build 必定失败
   go.mod 只 require 一个 gitcode 模块版本号且不生成 go.sum。gitcode 不在
   proxy.golang.org 上，于是：
     go build     → missing go.sum entry
     go mod tidy  → 去公共 proxy 拉一个不存在的条目，超时
   原来 cmdBuild 里那句 `go mod download <mod>` 走的正是这条死路，失败后
   只打一行 warn 就继续编译，紧接着死在同一个错误上——用户看到两段无关报错。

   修法分两处：
   - 生成的 go.mod 直接写指向本机 SDK 的 replace（replace 到目录时 go 不
     需要也不校验 go.sum）
   - 新增 ensureSDKResolvable：三级策略（已有本地 replace → 探测本机 SDK
     并写入 → 兜底 go mod tidy 带 -mod=mod，失败给可操作提示）。存量项目
     go.mod 无 replace 时走第二级救回。

bin/ 5 个预编译二进制不再进仓库（改为 release 附件）：
5 个平台各 26-28MB，每次重编都在 git 历史里再叠一份，而它们本质是可从源码
复现的产物。README 的下载说明同步改为 release 附件 URL + 从源码编译。

README_EN.md

@@ -142,14 +142,30 @@ Plugin developers only need to implement the `Plugin` interface and export a `Ne
 
 ## plugindev Toolchain
 
-`plugindev` provides full development workflow support:
+`plugindev` provides full development workflow support. Prebuilt binaries ship as **release assets**
+(linux/darwin/windows × amd64/arm64); download from
+[Releases](https://gitcode.com/JianFeeeee/homeagent-sdk/releases) and put it on your PATH:
+
+```bash
+# From release assets (v1.0.0 / linux amd64 shown)
+curl -Lo plugindev https://gitcode.com/JianFeeeee/homeagent-sdk/releases/download/v1.0.0/plugindev_linux_amd64
+chmod +x plugindev
+
+# Or build from source
+cd tools/plugindev && go build -o plugindev .
+```
+
+> Binaries no longer ship inside the repository (the old `bin/` directory is retired): five
+> platforms at 26-28MB each piled another copy into git history on every rebuild, and they are
+> reproducible from source anyway.
 
 | Command | Description |
 |---------|-------------|
-| `plugindev init` | Initialize plugin project (generates plg.json, entry template) |
-| `plugindev build` | Build plugin, output .hmap package |
-| `plugindev clean` | Clean build artifacts |
-| `plugindev debug` | Run plugin in local debug mode |
+| `plugindev init <name> [--lua]` | Initialize plugin project (generates plg.json, plugin.go or main.lua, go.mod, README.md) |
+| `plugindev build [flags]` | Build and package into a `.hmap` (supports cross-compilation and bundle mode) |
+| `plugindev clean` | Clean `build/` and `dist/` plus generated files |
+| `plugindev debug [dir]` | Load plugin source through the Yaegi Go interpreter and start an interactive REPL |
+| `plugindev sdk <command>` | SDK version management (list/install/use/path/current/latest) |
 
 Supports both **Go** and **Lua** plugin languages.
 
@@ -163,7 +179,7 @@ Supports both **Go** and **Lua** plugin languages.
   "version": "1.0.0",
   "description": "Weather plugin",
   "author": "HomeAgent",
-  "entry": "plugin.so",
+  "entry": "plugin.bin",
   "tags": ["weather", "forecast"],
   "targets": "linux/amd64,windows/amd64",
   "outdir": "dist",
@@ -185,7 +201,7 @@ Supports both **Go** and **Lua** plugin languages.
 | `version` | string | Version |
 | `description` | string | Plugin description |
 | `author` | string | Author |
-| `entry` | string | Entry file (`plugin.so` / `main.lua`) |
+| `entry` | string | Entry file (`plugin.bin` / `main.lua`). Since v1.0.0 Go plugins uniformly build to `plugin.bin`—no per-platform suffix |
 | `tags` | string[] | Tags |
 | `targets` | string | Build targets, comma-separated (e.g. `linux/amd64,windows/amd64`) |
 | `outdir` | string | Output directory (default `dist`) |
@@ -198,10 +214,15 @@ Supports both **Go** and **Lua** plugin languages.
 `.hmap` is a ZIP archive containing:
 
 - `plugin.json` — plugin metadata
-- `plugin.so` — Go compiled artifact (Linux)
-- `plugin.dll` — Go compiled artifact (Windows)
+- `plugin.bin` — Go compiled artifact (single-platform build)
+- `plugin.bin.<goos>.<goarch>` — one per platform in bundle mode; on install pluginmgr picks
+  the one matching the current platform and renames it to `plugin.bin`
 - `main.lua` — Lua plugin entry (for Lua plugins)
 
+> Since v1.0.0 `plugin.so`/`plugin.dll`/`plugin.dylib` are no longer used—the process boundary
+> *is* the ABI boundary, so there is no platform-specific shared-library distinction. The new
+> kernel will not load old artifacts; it emits an explicit rebuild hint instead.
+
 ## Plugin Lifecycle
 
 ### Start & Stop