feat(_release-rust): opt-in Debian .deb build

[emmanuelm41]

What

Adds an opt-in Debian .deb build to the reusable _release-rust.yml workflow, mirroring the existing enable_signing opt-in pattern.

How

• New workflow_call input build_deb (boolean, required: false, default false). Default off → 100% backward-compatible, so v10 can keep floating to main.
• All new steps are gated on inputs.build_deb && contains(matrix.target, 'linux').
• Installs cargo-deb via taiki-e/install-action@v2 (tool: cargo-deb).
• Builds with cargo deb --no-build --target ${{ matrix.target }} --output <deb> — no recompile; it packages the binary already built/stripped/signed earlier in the job.
• Per-arch: x86_64-unknown-linux-musl → amd64, aarch64-unknown-linux-musl → arm64.
• Asset named kache_<version>_<arch>.deb, where <version> = github.ref_name with a leading v stripped (the same ref the release job uploads under).
• Signed with the same zondax/actions/sign-linux-binary@v1 action and identical secrets as the other Linux assets → produces <deb>.asc.
• Checksummed (<deb>.sha256) like every other asset.
• The .deb, .deb.asc, .deb.sha256 are uploaded through the same upload-artifact → gh release upload mechanism as the rest.

Consumer requirement

The consuming repo's Cargo.toml must define:

[package.metadata.deb]
depends = ""   # static musl binary → no shared-lib deps; avoids dpkg-shlibdeps failure

No Cargo metadata is added here — that belongs to the consumer repo.

Merge order

Merge this and move v10 BEFORE the kache repo passes build_deb: true.