fix(plugins): reject path traversal in manifest identity before the install rm

[Weegy]

Fixes a path traversal in the plugin install pipeline that is exploitable today, independent of any epic. Found while planning #470; landing it standalone so it does not wait on unrelated decisions.

The chain

1. manifestLoader.ts reads identity.id / identity.version from the uploaded manifest with no charset validation — the only check is if (!id || !name || !version) return null.
2. packageUploadService.ts builds finalDir = path.join(packagesDir, plugin.id, plugin.version).
3. It then runs fs.rm(finalDir, { recursive: true, force: true }) followed by fs.rename(packageRoot, finalDir).

Verified on this machine:

path.join('/app/.uploaded-packages', '..', 'migrations')  ===  '/app/migrations'

So a manifest declaring identity.id: '..' and identity.version: 'migrations' deletes the real migrations directory and replaces it with attacker-controlled package content. At next boot the migrator does a readdir of exactly that path and executes every .sql it does not already have in its ledger.

Not operator-only. The same ingest() path is reached from routes/registryInstall.ts (ZIPs fetched from a remote plugin registry), profileBundleImporter.ts (plugin ZIPs vendored inside an imported profile bundle), dependencyChainResolver.ts and builder/installCommit.ts.

Today .sql is not in the ZIP extension allowlist, which limits this to arbitrary directory delete/replace rather than SQL execution. That allowlist entry was proposed as part of #470 — this fix is a hard prerequisite for it, and the reason it was pulled from that batch.

The fix — two independent layers

Layer 1, manifestLoader.ts: strict patterns for identity.id (npm-style, optionally scoped) and identity.version. Reject, never sanitise.

Layer 2, packageUploadService.ts: re-assert containment before the destructive fs.rm — path.resolve(finalDir) must stay under path.resolve(packagesDir). Defence in depth: the service layer does not rely on the loader having stayed correct. Also guards a small set of reserved root entries (notably the node_modules symlink the store plants, where a rename would land in the host's real node_modules).

Verification

An independent adversarial review pass reproduced every claim on a clean checkout and found no critical, high or medium issues. It probed the patterns directly — .., ., ...., ..a, a/../.., /etc/passwd, a/b, @../a, @a/.., %2e%2e, backslash forms, NUL bytes, spaces, uppercase, leading -/_ all rejected — and confirmed that values which pass and look suspicious (a.., 1.0.0-.., @a../b) still resolve to a single contained path segment.

It also checked a symlink bypass is unreachable: zipExtractor rejects symlink entries outright, and every intermediate path segment is created by fs.mkdir, never from archive content.

Compatibility: all 19 in-repo manifest.yaml identities and all 8 in omadia-byte5-plugins pass both patterns. AgentIdSchema / SemverSchema in the Builder are strict subsets, so no Builder output is rejected.

Test plan

• 46 new tests in middleware/test/pluginInstallPathTraversal.test.ts, stable across 3 isolated runs
• Traversal attempts rejected: .., a/../.., absolute paths, URL-encoded, backslash separators, NUL
• Legitimate scoped names (@omadia/plugin-office) still install
• The destructive fs.rm is proven not reached for a rejected package
• Full middleware suite: 5,193 pass. One intermittent single failure is the repo's documented load-sensitive flakiness — reproducible with a file of 48 trivial assertions, and absent from the baseline
• Typecheck + lint clean

Known follow-ups (low, not blocking)

• identity.version has no length cap, so a semver-legal 600-char version reaches fs.rm and throws ENAMETOOLONG as a 500 rather than the 422 every other malformed-manifest path returns.
• A manifest rejected by the new gate is reported to the uploader as package.manifest_invalid ("schema_version"), which misdiagnoses the cause; the charset is also undocumented in docs/creating-plugins.md.
• The gate runs at catalog-load time too, so an already-installed plugin with a non-conforming identity would disappear on restart while its registry entry stays active. No in-repo or byte5 plugin is affected.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}