Release: a zed release group, TOML version actions and zed-v tags

[imshaikot]

Part of the Zed work (tracked in #9). Depends on #4 existing; independent of the server.

Why

Zed's registry pins a commit of this repository and reads the version from apps/zed/extension.toml at that commit, so the committed TOML must carry the released version. Nx Release versions package.json by default; the Zed project needs its own manifest handling, its own release group and its own tag, so a Zed release never touches the VS Code extension or the npm packages, and theirs never touch it.

What

• nx.json: a zed release group (projects: ["tag:publish:zed"], releaseTag.pattern: "zed-v{version}"). Version plans work as for the others: yarn nx release plan minor --projects=zed -m "…".
• A custom Nx VersionActions (the abstract class in nx/dist/src/command-line/release/version/version-actions.d.ts; @nx/js's is the model): validManifestFilenames = ["extension.toml"], readCurrentVersionFromSourceManifest parses version = "…", updateProjectVersion rewrites the version line of extension.toml and Cargo.toml, no dependencies (readCurrentVersionOfDependency → null, updateProjectDependencies → []). Lives in tools/release/ and is named in apps/zed/project.json under release.version.versionActions (the project-level override the schema allows).
• release.yml: the npm job's if gains && !startsWith(github.ref_name, 'zed-v'); a new zed job on zed-v* checks the tag against extension.toml, runs the Rust build check (CI: build and package apps/zed with Rust and the zed-extension CLI #6's steps), then the submit script (Release: submit.mjs opens the PR to zed-industries/extensions on a zed-v tag #7).
• Docs: release section of CLAUDE.md, README and the monorepo skill (tag table gains zed-v<version>; the dry-run list gains the Zed line).

Checks

yarn nx release --dry-run --skip-publish with a Zed plan shows extension.toml and Cargo.toml bumped and the tag zed-v…; a VS Code-only plan leaves apps/zed untouched.