fix: move zod to peerDependencies

[mrsimpson]

so plugin shares OpenCode's zod instance

High level changes

• packages/opencode-plugin/package.json: Moved zod from dependencies to peerDependencies (version >=4.1.8), marked as non-optional
• pnpm-lock.yaml: Updated to reflect the dependency change
• .vibe/development-plan-fix-opencode-plugin-parameter-descriptions.md: Added EPCC plan documenting root cause analysis and fix strategy

Motivation

Parameter descriptions defined via .describe() on Zod schemas in our plugin tools were silently stripped from the JSON Schema sent to the LLM. This caused the AI to not understand parameter meanings — most critically, which workflow names are valid for start_development, leading to incorrect workflow selection.

Root cause: our plugin loaded its own Zod 4.3.6 instance while OpenCode used Zod 4.1.8. In Zod v4, .describe() stores descriptions in a module-level globalRegistry singleton. Since two separate instances were loaded, the plugin registered descriptions in its own registry, but OpenCode's z.toJSONSchema() read from its own (empty) registry — resulting in all descriptions being absent.

Details

• tsup.config.ts already had external: ['zod'], meaning zod was architecturally intended to be provided by the host — but package.json still listed it as a dependency, causing pnpm to install a separate copy in the plugin's node_modules
• Moving zod to peerDependencies ensures consumers (OpenCode) provide their own zod instance, so both sides share a single globalRegistry
• All 5 tool handlers that use .describe() benefit: start_development, proceed_to_phase, conduct_review, reset_development, setup_project_docs
• No source code changes required — the .describe() calls in tool handlers remain identical