stash init --drizzle installs EQL v2 instead of v3 #732

stash init --drizzle is the only flow still provisioning an EQL v2 database. A bare stash eql install and init for every other integration already default to v3.

packages/cli/src/commands/init/steps/install-eql.ts:103
    eqlVersion: drizzle ? '2' : undefined,

The pin's stated reason — "the Drizzle migration path is v2-only" — stopped being true when stash eql migration --drizzle shipped (#690). skills/stash-drizzle/SKILL.md didn't just document the pin, it justified it with the same now-false claim.

The pin was causing the mismatch it appeared to prevent

Init installs stash-encryption, stash-drizzle and stash-cli into the customer's repo, and both content skills are fully v3 — they teach EncryptionV3, types.*, and public.eql_v3_*. So init --drizzle handed the customer's coding agent v3 guidance against a v2 database it had just provisioned. Every new Drizzle customer running stash init was being put on the generation slated for removal (#707).

Why it's more than flipping the flag

routeInstallPathForEqlVersion forces drizzle: false under v3, so a bare flag flip would have silently converted Drizzle projects to a direct install and lost their migration history. The fix routes init's Drizzle branch through eqlMigrationCommand({ drizzle: true, embedded: true }) — v3 SQL, still migration-first.

Fix

PR #705. Also fixes eql install --drizzle's rejection message, which was actively steering users to --eql-version 2. install-eql.test.ts goes from 5 tests to 11, including a regression guard on the v2 pin.

Follow-up (not in this PR)

generatePlaceholderClient emits v2 pattern comments and Encryption({ schemas: [] }) for all integrations, not just Drizzle — so Supabase and plain-Postgres init already ship a v3 database with a v2 placeholder client. Pre-existing and broader than this fix; self-contained (two string constants plus commands/schema/build.ts).