feat(plugins): install npm sources and review CLI updates

Treat install selectors as one-time choices. Keep source identity separate from the installed revision, and resolve ordinary updates from the current upstream default. npm only acquires directories; plugin loading remains independent of npm.

docs/data-model.md

@@ -64,8 +64,8 @@ $PASEO_HOME/
 │   └── managed-processes/
 │       └── {recordId}.json              # Helper processes owned by Paseo; reconciled on daemon bootstrap
 ├── plugins/
-│   ├── sources.json                      # Git origin, ref, commit, and managed checkout ownership
-│   └── {pluginId}/{version}/checkout/    # Source checkout for one installed Git commit
+│   ├── sources.json                      # Managed kind and Git acquisition remote
+│   └── {pluginId}/{uuid}/                # Git checkout or npm package/lockfile/dependency tree
 └── push-tokens.json                     # Expo push notification tokens
 ```
 
@@ -254,11 +254,13 @@ snapshot so a mixed edit can apply its live subset and still name the paths that
 
 All fields are optional with sensible defaults.
 
-Git-managed plugins still appear as directory sources in `config.json`. This keeps the plugin
-runtime and protocol config compatible with directory-only clients. `plugins/sources.json` owns the
-Git-specific origin, tracking ref, installed commit, repository subdirectory, and checkout root.
-Paseo writes it atomically. An update creates and validates a new version directory before changing
-the configured directory path; successful activation removes the old version.
+Managed plugins appear as directory sources in `config.json`; it owns the active path and enabled
+state. `plugins/sources.json` is written atomically and stores only managed kind and the Git acquisition
+remote. Installed revision, package/subdirectory identity and ownership root come from retained
+artifacts and the fixed managed layout; [managed source ownership](plugins.md#managed-source-ownership)
+explains their authority. An update prepares a new directory before replacing the active path and
+removing the previous version. Old record fields are accepted at the store boundary and ignored;
+there is no startup migration or persistent update policy.
 
 ### Profile lists
 

docs/plugins.md

@@ -4,7 +4,7 @@ Local plugins contribute daemon RPCs, native app surfaces, workspace panels, Com
 client slash commands, timeline items, header buttons, composer pills, app themes, composer attachment sources, and settings screens.
 Paseo executes `index.server.ts` in a subprocess and `index.client.tsx` in every connected app.
 
-> **Trust every plugin you add.** `paseo plugin add` and `paseo plugin install` mean “I trust this codebase.” Plugins are unsandboxed: server code and Git preparation commands run with the daemon user's access on the daemon host, and client contributions run inside Paseo. The repository's dependencies and future updates are part of that trust decision. With `--host`, preparation runs on that remote daemon host.
+> **Trust every plugin you add.** `paseo plugin add` and `paseo plugin install` mean “I trust this codebase.” Plugins are unsandboxed: server code and preparation commands run with the daemon user's access on the daemon host, and client contributions run inside Paseo. The repository's dependencies and future updates are part of that trust decision. With `--host`, preparation runs on that remote daemon host.
 
 ## Install a directory source
 
@@ -103,10 +103,36 @@ paseo plugin update --all
 
 Append `:relative/path` to the source when the plugin lives below the repository root.
 
-Omitting `--ref` tracks the remote's default branch. A branch passed with `--ref` also tracks;
-tags and commits stay pinned. `ls` reports the installed commit without contacting the remote.
+`--ref` chooses the initial branch, tag, or commit once. Ordinary updates resolve the remote's
+current default HEAD and ask for approval. `ls` reports the installed commit without contacting the remote.
 Removing a Git source deletes Paseo's managed checkout.
 
+## Managed source ownership
+
+The [public source reference](../public-docs/plugins/v0.8/reference.md#plugin-sources) owns identifier
+syntax, npm prerequisites, and publishing instructions. Both clients send the source unchanged
+through `installPluginSource`; only the daemon resolves host paths and acquires sources.
+
+`ManagedPluginSources` owns acquisition and offline source description. Config stores the active
+directory; sources.json stores managed kind and the Git acquisition remote. The remote is needed
+because authenticated clones may have a rewritten placeholder origin. Fixed owned directory layout
+provides the selected subdirectory, npm package name and cleanup root. Git HEAD and the installed
+npm package.json checked against package-lock.json provide the current revision. Keep the complete
+npm dependency tree and lockfile after staging activation. No install selector governs updates.
+
+The loader sees only the configured directory and never invokes npm. npm lifecycle scripts are
+disabled during acquisition; manifest preparation owns required commands before validation.
+
+List responses retain the closed `source: directory | git` enum. The optional `installation`
+projection carries identity and current revision. Old npm metadata remains accepted but is no longer
+emitted. Installation uses `features.pluginSourceInstallation`; reviewed preview/apply uses
+`features.pluginSourceUpdates`, gated by the SDK and CLI entry. The old immediate-update request
+returns update-client guidance. Basic management remains independently available.
+
+Preview returns exact targets and expected installed identity/root/revision. Apply validates those
+values, acquires the displayed artifact or commit, then rechecks state before activation. No review
+session is stored in the daemon. PluginService owns activation/recovery and independent bulk results.
+
 ### Declare Git preparation
 
 Most plugins should omit `build`. Use it only when the staged checkout must install a dependency