fix(zed): use the bare version when locating the rcl-lsp release asset

[mentenaz]

Problem

In Zed, the extension (1.0.5) fails to start its language server:

Language server rcl-lsp:
from extension "React Component Lens" version 1.0.5: no release asset found matching
"rcl-lsp-react-component-lens(packages/vscode/package.json)@1.0.5-x86_64-pc-windows-msvc.zip"

zed::latest_github_release returns the release tag as version. Releases here are tagged per package, so the tag is not a bare version number:

	Value
Release tag	react-component-lens(packages/vscode/package.json)@1.0.5
Asset the extension asks for	rcl-lsp-react-component-lens(packages/vscode/package.json)@1.0.5-x86_64-pc-windows-msvc.zip
Asset that exists	rcl-lsp-1.0.5-x86_64-pc-windows-msvc.zip

The same mismatch applies on macOS and Linux, since every asset name is built the same way.

Fix

packages/zed/src/lib.rs only:

• Add release_version, which takes the part of the tag after the last @ (and drops a leading v from a plain tag).
• Use it for the asset name and for the install directory. The directory matters as well: the full tag contains / and parentheses.
• Two unit tests cover the package-scoped tags and plain 1.0.5 / v1.0.5 tags.

Testing

• cargo test -p rcl-zed: 2 passed.
• cargo fmt -p rcl-zed -- --check: clean.
• cargo build -p rcl-zed --target wasm32-wasip2: builds.
• Installed from this branch as a Zed dev extension on Windows (x86_64): rcl-lsp downloads and starts, and JSX tags are coloured in a .tsx file.
• Not tested on macOS or Linux. The release archive for Windows holds rcl-lsp.exe at its top level, which is where the extension looks for it; I did not inspect the .tar.gz archives.

Notes

• Cargo.lock on main still lists the workspace crates at 1.0.4 while their manifests say 1.0.5, so any build rewrites it. I left that out to keep this change to one file.
• I did not add a changepack entry, as I wasn't sure of the expected format. Happy to add one if you point me at it.

🤖 Generated with Claude Code

[owjs3901]

Please fix lint

[mentenaz]

The failing test check isn't testing this PR's code. The workflow runs on pull_request_target and actions/checkout has no ref, so it checks out main (the job log shows git checkout -B main refs/remotes/origin/main at 9a3c82d). main currently fails cargo clippy -D warnings on the latest stable toolchain (1.99, clippy::assert_is_empty in packages/lsp/src/main.rs). This PR includes the fix for those lints, and the full test job steps pass locally on Windows with bun 1.3.9, though only against Rust 1.95 — I couldn't run clippy 1.99 locally. The check should go green once this is merged.