bzlmod: override_target_build_script and override_target_proc_macro are silent no-ops (override_targets key mismatch)

The bzlmod module extension reconstructs `override_targets` from the four split `override_target_*` attributes using the keys `"build_script"` and `"proc_macro"`:

https://github.com/bazelbuild/rules_rust/blob/main/crate_universe/extensions.bzl (search for `override_target_build_script`)

```starlark
replacement = annotation_dict.pop("override_target_proc_macro")
if replacement:
annotation_dict["override_targets"]["proc_macro"] = str(replacement)

replacement = annotation_dict.pop("override_target_build_script")
if replacement:
annotation_dict["override_targets"]["build_script"] = str(replacement)
```

But rendering looks the rule up by its cargo-metadata `Target.kind` via `override_target_key()`, which returns `"proc-macro"` and `"custom-build"`:

https://github.com/bazelbuild/rules_rust/blob/main/crate_universe/src/context/crate_context.rs (`override_target_key`)

```rust
pub(crate) fn override_target_key(&self) -> &'static str {
match self {
Self::Library(..) => "lib",
Self::ProcMacro(..) => "proc-macro",
Self::Binary(..) => "bin",
Self::BuildScript(..) => "custom-build",
}
}
```

`"lib"` and `"bin"` agree in both spellings, so those overrides work. `"build_script"` and `"proc_macro"` never match, so under bzlmod `override_target_build_script` and `override_target_proc_macro` are silently ignored: the generated BUILD keeps its own `cargo_build_script` instead of emitting the alias to the override label. No error or warning is produced.

The non-bzlmod `crate.annotation(override_targets = ...)` documents the kind-style vocabulary ("Keys can be `proc-macro`, `custom-build`, `lib`, `bin`" in `crate_universe/private/crate.bzl`), which is presumably why this went unnoticed: WORKSPACE users pass the dict directly with the correct keys.

Repro: annotate any crate that has a build script with `override_target_build_script = "//some:target"` under bzlmod, repin, and inspect the generated BUILD: it still contains the generated `cargo_build_script` rather than an alias to `//some:target`.

Fix: align the two keys in `extensions.bzl` with the documented vocabulary:

```diff
- annotation_dict["override_targets"]["proc_macro"] = str(replacement)
+ annotation_dict["override_targets"]["proc-macro"] = str(replacement)
...
- annotation_dict["override_targets"]["build_script"] = str(replacement)
+ annotation_dict["override_targets"]["custom-build"] = str(replacement)
```

We are running with exactly this two-line patch applied to 0.70.0 and `override_target_build_script` works as documented with it.

Start in extensions.bzl at the reconstruction of override_targets and compare its keys with override_target_key in crate_context.rs. Align the bzlmod keys with the documented kind vocabulary, then repin a crate with a build script or proc macro and inspect the generated BUILD to confirm the override emits an alias to the supplied label.

Written by the indexing model from the issue text.