feat: SDK update for version 22.2.2

[ChiragAgg5k]

This PR contains updates to the SDK for version 22.2.2.

What's Changed

• Fixed: Release binaries now embed @napi-rs/keyring native bindings for all targets

[greptile-apps]

Greptile Summary

This PR updates the CLI release metadata and release workflow for version 22.2.2. The main changes are:

• Bumps CLI version references from 22.2.1 to 22.2.2.
• Updates installer and Scoop URLs to the new release tag.
• Adds a release workflow step to fetch @napi-rs/keyring native packages for all compiled targets.
• Documents the native binding release fix in the changelog.

Confidence Score: 4/5

The release metadata changes are straightforward, but the workflow's native package fetch path needs attention before the release process is safe to rely on.

The changed files are mostly version bumps and release packaging updates, with the main risk concentrated in the new workflow step that downloads native bindings outside normal package-manager verification.

.github/workflows/publish.yml

T-Rex Logs

What T-Rex did

• Ran a local mock-registry harness to generate a tampered tarball for @napi-rs/keyring-linux-x64-gnu and exercised the curl -fsSL URL | tar -xz -C node_modules/@napi-rs/keyring-linux-x64-gnu --strip-components=1 workflow.
• Verified that the extracted package contains attacker-controlled files (package.json, index.js, and a native .node placeholder).
• Noted that there was no npm, bun, shasum, or lockfile integrity verification gate between fetching the tarball and extracting it.
• Archived the tampered keyring package contents and prepared a listing to inspect the extracted files.
• Compared metadata between pre- and post-artifact states, observing base 22.2.1 in the initial references and head 22.2.2 in the updated paths.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "chore: update Command Line SDK to 22.2.2" | Re-trigger Greptile}

[greptile-apps]

Verify downloaded tarballs

This step downloads native packages outside the lockfile-verified install path and pipes them directly into tar. If the registry or a proxy returns a corrupted or tampered @napi-rs/keyring-* tarball, the workflow can embed that native code into signed release binaries without checking the integrity already recorded in the lockfiles. Please fetch these packages through the package manager or verify each tarball against lockfile integrity before extraction.

[greptile-apps]

Mirror release validation

The release workflow now fetches non-host keyring packages before compiling, but the CI build path still cross-compiles the same binaries without this step and only checks that output files are non-empty. When keyring embedding breaks for a non-host target, CI can still pass while the release-only path is the first place that exercises the new behavior. Please share this fetch/setup step with CI or add a CI check that confirms the compiled binaries contain the expected native keyring binding for each target.