Closes #5936.

The Rust Telegram sidecar (#5831) shipped only as source, so using it meant installing a Rust toolchain, cloning the repo, building librefang-sidecar-telegram, and pointing a [[sidecar_channels]] block at the resulting path.
This bundles the binary inside the existing release tarballs so librefang update lands it at ~/.librefang/bin/ and the daemon auto-resolves it — making the migration off the Python sidecar a one-step config change.

Part 1 — Release build (bundle inside existing tarballs)

Both workflows change in lockstep (release-cli.yml is the manual mirror of release.yml's CLI jobs).
For each channel-capable native target the in-scope jobs are cli_mac (x86_64 + aarch64), cli_linux (x86_64-gnu + aarch64-gnu[cross]), cli_musl (x86_64 + aarch64, both cross), cli_windows (x86_64 + aarch64).
Per job:

• A new "Build Telegram sidecar" step builds the sidecar for the same target with --manifest-path sdk/rust/librefang-sidecar-telegram/Cargo.toml (using cross where that job already uses cross — i.e. all of cli_musl, and the aarch64 leg of cli_linux).
• The Package step copies the sidecar binary (from its separate-workspace output sdk/rust/librefang-sidecar-telegram/target/<target>/release/) next to librefang and adds it to the same archive.
  macOS ad-hoc codesigns it like librefang; cli_musl verifies it is statically linked; Windows adds librefang-sidecar-telegram.exe to the Compress-Archive path list.

No new release assets are introduced — the binary ships inside the existing per-target librefang-<target>.tar.gz / .zip, so EXPECTED_PLATFORMS=12 and the cosign SHA256SUMS manifest are unchanged.

Deliberately skipped: the cli_android job and all mini variants (Android and mini carry no channels).

Part 2 — Install scripts (extract the bundled binary)

• install.sh (POSIX sh): after installing librefang, if librefang-sidecar-telegram is present in the extracted tarball, chmod +x it (and on macOS strip quarantine + ad-hoc codesign). Absent ⇒ skipped silently (backward compatible with older tarballs).
• install.ps1: mirror — if librefang-sidecar-telegram.exe is present, copy it to $InstallDir; absent ⇒ skipped.

Part 3 — Daemon auto-resolution

resolve_sidecar_command(command, home_dir) in crates/librefang-channels/src/sidecar.rs, called once in SidecarAdapter::new (where home_dir is already available, so the resolved command flows into both the adapter field and the spawn SpawnCtx):

• Eligible only when command is empty or the bare stem librefang-sidecar-telegram (no path component).
• Resolution order, first hit wins: the daemon's own executable directory (current_exe().parent()), then <home_dir>/bin/, then fall through to the original command (PATH lookup — historical behavior).
• An absolute / relative path, or any other program (python3, uv, ./librefang-sidecar-telegram, …), passes through unchanged so explicit operator intent always wins.

Three focused unit tests cover: resolves to <home>/bin when the bundled binary is present (bare stem and empty command); falls through unchanged when no bundled binary exists; leaves explicit commands untouched even when a bundled binary is on disk.

Part 4 — Docs + CHANGELOG

• docs/architecture/rust-telegram-sidecar.md and docs/src/app/configuration/channels/page.mdx now state the binary ships in release tarballs, lands in ~/.librefang/bin/ via librefang update, and is auto-resolved — manual build no longer required. Added an "Auto-resolution" section documenting the search order.
• CHANGELOG.md entry added under the existing [Unreleased] ### Added.

Verification

Run via the repo's Dockerfile.rust-dev image (no native cargo on the host; Linux container, scoped commands only):

• cargo test -p librefang-channels --lib → 482 passed, 0 failed (includes the 3 new resolve_sidecar_command_* tests, confirmed passing individually).
• cargo build --release --manifest-path sdk/rust/librefang-sidecar-telegram/Cargo.toml → compiles clean, binary produced (~8 MB).
• cargo clippy -p librefang-channels --all-targets -- -D warnings → clean.
• cargo fmt -p librefang-channels -- --check → clean.
• sh -n web/public/install.sh → syntax OK (shellcheck not available on the host).
• release.yml / release-cli.yml validated as YAML.

Not locally verifiable — needs CI on a real tag

The release pipeline itself cannot be exercised locally (no tag, no GitHub Actions runners, and cargo build for the kernel is forbidden in-session).
The workflow edits — the cross-compiled sidecar build steps, the cross --manifest-path invocation for the separate workspace, the macOS codesign / musl static-link / Windows zip packaging, and the assertion that asset names and the EXPECTED_PLATFORMS=12 / cosign manifest are unchanged — must be validated by CI on a real tag (or a release-cli manual dispatch).
The sidecar build was proven to compile for the container's Linux target only; per-target cross builds (aarch64, musl, Windows, macOS) are CI's responsibility.

Update — PR-time CI guard (post-review)

Added a PR-time guard so the sidecar's compilability and the cross-compile risk are no longer deferred to CI-on-tag.

• ci.yml: new changes output sidecar_rust (set when sdk/rust/librefang-sidecar{,-telegram}/ or the release workflows change), feeding a new rust-telegram-sidecar job modeled on the existing skills-wasm-sdk job.
  The job runs cargo fmt --check + clippy -D warnings + test + build --release on the sidecar workspace, then cargo install cross + cross build --release --target aarch64-unknown-linux-musl --manifest-path sdk/rust/librefang-sidecar-telegram/Cargo.toml.
  That cross step really runs cross on this PR, proving up front whether cross can mount and resolve the out-of-workspace ../librefang-sidecar path dependency — the exact risk the original PR could only flag as "needs CI-on-tag validation".
  rust-cache lists both sdk/rust/librefang-sidecar-telegram and the sibling sdk/rust/librefang-sidecar.
• release.yml + release-cli.yml: the four native sidecar-building jobs (mac / linux / musl / windows) now cache the sidecar's separate target/ by listing . and sdk/rust/librefang-sidecar-telegram under rust-cache workspaces: (mini / android untouched).

If the cross step fails on this PR's CI, that is the real answer we couldn't get locally — it would mean the sidecar workspace needs a Cross.toml / mount tweak so cross can see ../librefang-sidecar (a follow-up).

Local verification (Docker dev image) of the native rust-telegram-sidecar step: cargo fmt --check clean, clippy --all-targets -- -D warnings clean, cargo test 41 passed, cargo build --release OK.
All three workflow YAMLs pass yaml.safe_load and actionlint.
The cross-musl step is intentionally CI-only.