a63da8a3a3
The #3063 fix introduced a second mutating step — `bun update <name>` — that rewrites bun.lock before extension validation runs. Three failure paths could still leave the rejected commit pinned in the lockfile or active tree: - Extension validation throwing after `bun update` had refreshed bun.lock — rollback restored package.json and node_modules/<name> but never touched bun.lock. - Feature validation (`omp plugin install pkg[ghost]`) throwing outside the rollback block entirely. - Runtime-config save failing after a successful install with no rollback path. Snapshot bun.lock alongside package.json before `bun install` runs and route every post-install step (resolution, update, package.json read, feature validation, extension validation, runtime-config save) through one outer catch that restores all three (package.json + bun.lock + node_modules/<name> from snapshot). `#rollbackFailedInstall` now tolerates an unresolved `actualName` for failures that throw before the dep key is known. Three regression tests in plugin-install-validation.test.ts pin the new contract: bun.lock restoration after a git reinstall fails validation, bun.lock removal when it didn't exist pre-install, and rollback on an unknown feature request. Addresses review feedback on #3069.