feat(ci/cd): Add `cargo deny` as a pre-merge CI check

### Description

**Type:** ci / security
**Labels:** `security`, `ci`, `dependencies`, `A-tooling`
**Source:** discussion [#3678](https://github.com/apache/iggy/discussions/3678)

## Summary

Wire `cargo deny` into the pre-merge CI pipeline
(`.github/actions/rust/pre-merge`) so every PR is gated on advisory scanning,
license policy, banned crates, and duplicate-version detection across the full
dependency graph. Mirror the check in the local pre-commit config so
contributors catch failures before pushing.

## Motivation

`cargo audit` only covers known vulnerabilities. `cargo deny` is a superset
gate: in addition to RustSec advisories it enforces open-source license policy,
bans specific crates, and flags duplicate dependency versions. A pre-merge gate
prevents new advisories and policy violations from re-entering the tree after the
one-time remediation (sibling audit issue) lands.

Reference:

### Affected area / component

Other / not sure

### Proposed solution

## Proposed approach

1. Add a committed `deny.toml` at repo root with sections:
- `[advisories]` — deny vulnerabilities/unsound; explicit `ignore` list for
accepted-risk advisories (each with a comment + review date). Seed from the
audit-remediation issue outcomes.
- `[licenses]` — allowlist ASF-compatible licenses (Apache-2.0, MIT,
BSD-2/3-Clause, ISC, Unicode-DFS, etc.); confirm against the existing
`scripts/ci/third-party-licenses.sh` policy so the two do not conflict.
- `[bans]` — flag duplicate versions (`multiple-versions = "warn"` initially,
then `deny` once the tree is deduplicated); ban known-bad crates.
- `[sources]` — restrict to crates.io + explicitly allowed git sources.
2. Add a CI step running `cargo deny check` (advisories, licenses, bans, sources)
inside `.github/actions/rust/pre-merge/action.yml`, ordered after the existing
Rust verification steps.
3. Add a `scripts/ci/cargo-deny.sh` wrapper (consistent with existing
`scripts/ci/*.sh`) and wire it into `.pre-commit-config.yaml`.

### Alternatives considered

_No response_

### Contribution

- [x] I'm willing to submit a pull request to implement this feature

### Good first issue

- [x] I think this could be a good first issue for a new contributor