chore(e2e): install from the root npm workspace

[ofir-starkware]

Stacked on #1008 (PR 3 of 3 in the npm-workspace stack; #1007 → #1008 → this).

What

• Adds e2e to the root workspace. Its file: links to sdk, client and proof-interceptor become semver ranges, and npm links the local packages for them.
• Merges e2e/package-lock.json into the root lockfile:
  • it adds no package versions that weren't already locked;
  • there's still a single starknet copy across the workspace.
• CI:
  • e2e-devnet and e2e-integration install once from the root (npm ci && npm run build -w sdk). The separate cd e2e && npm ci steps are removed.
  • e2e-devnet's path filters now include the root package.json and lockfile.
• Docs:
  • The root README, e2e/README.md and the E2E gate in .claude/rules/verification.md describe the workspace install.
  • The gate rule also now names target/release/, which is where E2E actually spawns discovery-service from. It previously said target/debug/.
• Separate commit: a whitespace-only prettier fix to e2e/scripts/batch-operations.ts, which already failed prettier --check e2e/scripts/ on main.

Why

• This completes the move started in chore(client): move sdk and client into an npm workspace with a peer SDK dependency #1007. Every TypeScript package except demo now installs from one lockfile, and none of them links another through file:.
• demo stays out on purpose: its starknet override and its starknet-sdk alias don't fit a shared workspace.

Verification

• Fresh root npm ci works.
• All members build. sdk, client and proof-interceptor lint cleanly.
• e2e/scripts passes prettier --check and eslint, and npm run lint:check passes.
• Tests: sdk test:fast 27/27 files, client 66/66, proof-interceptor 200/200.
• E2E resolves all three local packages to their built dist/.
• E2E devnet suite, run locally: 15/15 files, 28/28 tests.

🤖 Generated with Claude Code

---

This change is 

[semgrep-code-starkware-libs]

High severity vulnerability may affect your project—review required:
Line 2507 lists a dependency (vite) with a known High severity vulnerability.

ℹ️ Why this matters

Affected versions of vite and vite-plus are vulnerable to Exposure of Sensitive Information to an Unauthorized Actor / Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'). Vite's server.fs.deny blocklist—which protects sensitive files such as .env and certificate files from being served—can be bypassed on Windows using alternate path representations (NTFS Alternate Data Stream syntax like /.env::$DATA?raw, or 8.3 short filenames), allowing an attacker to read otherwise-denied files when the dev server is exposed to the network.

References: https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-38303, GHSA, CVE

To resolve this comment:
Check if you expose the Vite dev server or vite-plus to the network by configuring a non-loopback address using the --host CLI flag on Windows.

• If you're affected, upgrade this dependency to at least version 8.0.16 at package-lock.json.
• If you're not affected, comment /fp we don't use this [condition]

💬 Ignore this finding

To ignore this, reply with:

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

_{You can view more details on this finding in the Semgrep AppSec Platform here.}