[kumarUjjawal]

Which issue does this PR close?

Closes #26181.

Rationale for this change

On main at 2717e25625ff0c51c1805f8df52d317979db74ec, cargo clippy --all-targets --all-features -- -D warnings fails with two clippy::mutable_key_type errors in alias_aggregate_exprs and rewrite_select_aggs.

The diagnostics follow Expr through nested ScalarValue arrays to Arrow's TrackedReservation. That mutable memory accounting does not affect expression equality or hashing. The earlier PushDownFilter occurrences discussed in #26189 are already fixed on main.

What changes are included in this PR?

Add explained lint allowances on the aggregate rewrite map declaration and rewrite_select_aggs, following existing Expr key handling. No runtime code changes.

What is the testing strategy for this PR?

• Reproduced both errors on unmodified main; the exact command passes with this change.

• cargo fmt --all and git diff --check pass.

• uv run ./dev/rust_lint.sh passes, including CI Clippy, dependency checks, and documentation builds.

• All 240 existing DataFrame integration tests pass, including test_dataframe_api_select_semantics, aggregate aliases, and name collisions.

• Extended workspace validation passes: 12,819 Rust tests passed, 8 ignored, and 538 SQL logic test files completed:

  RUST_BACKTRACE=1 cargo test --profile ci \
    --exclude datafusion-examples --exclude datafusion-benchmarks --exclude datafusion-cli \
    --workspace --lib --tests --bins \
    --features avro,json,backtrace,extended_tests,recursive_protection,parquet_encryption

No new runtime tests or benchmarks: this change adds only lint attributes and explanatory comments.

Are there any user-facing changes?

The documented all-features Clippy command passes again. No SQL behavior or public API changes.

[neilconway]

I'm fine landing this as-is, but I wonder if it would be cleaner to add this to clippy.toml

ignore-interior-mutability = ["bytes::Bytes", "arrow_buffer::TrackedReservation"]

[alamb]

And maybe should we add a CI check to prevent it again?

[kumarUjjawal]

And maybe should we add a CI check to prevent it again?

I have opened a pr for that #26591

I will land that after this gets merged.