Zed: first submission (fork, token, manual test in Zed, review)

[imshaikot]

Part of the Zed work (tracked in #9). Last step; depends on #3, #4, #5, #6 and #7.

Zed's prerequisites require the extension to be tested in Zed at the exact submodule commit submitted, and reviewers try it. This checklist is that first submission.

One-time setup

• Fork the registry: gh repo fork zed-industries/extensions --clone=false → imshaikot/extensions.
• A GitHub token that can push to the fork and open PRs on zed-industries/extensions (fine-grained: contents and pull requests on the fork, or a classic repo token); add it as the repository secret ZED_EXTENSIONS_TOKEN.
• Locally: rustup with wasm32-wasip2, and Zed installed.
• @orbit-code/server published to npm (a server-v* release), at the version SERVER_VERSION in apps/zed pins.

The release

• yarn nx release plan minor --projects=zed -m "…", commit; yarn nx release --dry-run --skip-publish, then for real; check the release commit against the commit conventions (no attribution trailers).
• Before pushing the tag: in Zed, zed: install dev extension on apps/zed at that commit; in the agent panel's MCP settings enable Orbit, confirm the server starts, its tools are listed, orbit_open opens the page on this repository, a turn from the page works, and an edit in Zed shows as a live update.
• git push --follow-tags: release.yml's zed job builds, packages and runs submit.mjs, which opens the PR from the fork. Check it: one extension, path = "apps/zed", the version, sorted files, the submodule commit on main.
• Watch the registry's CI on the PR (it packages apps/zed with the pinned zed-extension CLI and validates the license); answer review within three weeks.
• After the merge: install it from Zed's extensions page, and add a "Use it in Zed" line to the root README and apps/zed/README.md.

Later releases

A version plan, yarn nx release, push the tag; the job opens the update PR (a submodule bump plus the version line). Keep at most three open PRs there.