feat: make webjs.nvim self-contained (bundle @webjsdev/ts-plugin)

[vivek7405]

Problem

webjs.nvim currently relies on the app having @webjsdev/ts-plugin in its node_modules for language intelligence (tsserver resolves plugins from the project's node_modules). That leaks an internal dependency to the user: installing webjs.nvim alone is not enough. The VS Code extension already bundles the plugin; webjs.nvim should too, so it is one-install all-in-one.

Approach

tsserver accepts plugins from explicit probe locations (init_options.plugins[].location in typescript-language-server / vtsls, which becomes tsserver pluginProbeLocations). Since @webjsdev/ts-plugin is now standalone, dependency-free plain CJS (#386), webjs.nvim can VENDOR a verbatim copy of it and point tsserver at the bundled location.

• Vendor packages/ts-plugin/{package.json, src/} into packages/nvim/vendor/node_modules/@webjsdev/ts-plugin/ via a sync script, COMMITTED (lazy.nvim has no build step, so the bundle must be present after clone).
• require('webjs').with_tsserver_plugin() returns { plugins = {{ name = '@webjsdev/ts-plugin', location = <plugin_root>/vendor }} } so tsserver loads the vendored copy, NOT the app's node_modules.
• A test asserts the vendored copy is in sync with packages/ts-plugin/src (drift guard), plus a headless check that the location resolves.

Consequence

After this, neither editor plugin requires the app to install @webjsdev/ts-plugin. The npm publish of @webjsdev/ts-plugin becomes optional, needed ONLY for JetBrains / hand-wired-tsconfig users (and the scaffold pin that serves them). Keeping it for now.

Acceptance criteria

• webjs.nvim ships a vendored @webjsdev/ts-plugin and with_tsserver_plugin() points tsserver at it.
• Installing only webjs.nvim (no app dependency) yields go-to-def / completions / diagnostics in an html template.
• A drift test fails if the vendored copy diverges from packages/ts-plugin/src.
• README / doc / AGENTS updated; PUBLISHING note about re-vendoring before a subtree split.

Follow-up to epic #381 (Phase 4 #387).

[vivek7405]

Scope expanded per owner decision: also drop @webjsdev/ts-plugin from the scaffold entirely (no JetBrains / node_modules path wanted). After this, neither editor plugin needs the app to install it (both bundle it), so a generated app's node_modules no longer carries ts-plugin. The tsconfig plugins entry + the devDependency are removed from webjs create; the manual npm i -D @webjsdev/ts-plugin path remains available but is no longer the default. Editor docs updated to lead with the extensions.

[vivek7405]

Closing: decided NOT to bundle ts-plugin into webjs.nvim. Research (Next.js) confirmed the cleaner model: Neovim's ts_ls auto-loads a tsconfig plugin from the app's node_modules (no workspace-TS gate like VS Code), so a scaffolded app's @webjsdev/ts-plugin already gives Neovim the intelligence. Bundling it again in webjs.nvim is redundant and risks a double-load (tsconfig + init_options). webjs.nvim keeps providing what node_modules can't: treesitter highlighting + :WebjsCheck + health, and relies on the app's tsconfig plugin (with_tsserver_plugin() stays as the helper for apps that have ts-plugin in node_modules but not in tsconfig). Only @webjsdev/ui leaves the scaffold (#399).

[vivek7405]

Reopening: decision reversed to Combo B. The deciding factor is the 'user hasn't run npm install yet' case (and pruned node_modules / non-scaffolded apps): a node_modules-dependent Neovim plugin gives no intelligence on a fresh clone, while the bundled VS Code extension works immediately. That asymmetry is unfair. So BOTH editor plugins become self-contained (bundle ts-plugin), and the scaffold stops wiring ts-plugin into tsconfig (no double-load). webjs.nvim bundles ts-plugin and points tsserver at it via the probe location; the VS Code extension already bundles it. This supersedes the earlier 'rely on the app's tsconfig' conclusion.