A proxy group needs a name on the raft path too

[bjmeetsfo]

put_proxy_group refuses a group that names neither itself nor a namespace.
That check lived only in the public method, and the propose path dispatches
straight to apply_put_proxy_group, which does not check.

Measured

The same request, both backends:

single-node -> ok=false code=bad_request groups=0
raft        -> ok=true  code=ok          groups=1
               group name="" namespace="" location="rack-1"

A nameless group is committed into replicated metadata by the raft path and
refused outright by the single-node one.

Why it does not simply sit there harmlessly

The group name is the key it is stored under, and an empty name is also the
value an unattached proxy carries. So the group is indexed by "no group at
all", and calibration counts every idle proxy as already belonging to it. I
expected that to churn — plan an attach every round, forever — and measured it
instead: three rounds, attach=[] detach=[] shortfalls=0. It does not churn.
It does something quieter: the phantom group reads as permanently satisfied by
proxies that are actually idle, so nothing ever reports it and nothing ever
cleans it up. It then survives snapshot and replay, because by that point it is
legitimately committed history.

The change

Judge it in admission_refusal, alongside the other pre-propose checks, and
let the public method go through that same judgement so the two cannot drift
apart again. Before proposing and never while applying — replay has to reapply
what was already accepted, which is why this does not go in apply_*.

The check takes no lock: it judges the request alone, not the state around it.

Test

The raft path now answers bad_request and stores nothing, matching the
single-node path, and a properly named group still goes through so the guard
is not simply refusing everything. It fails before the change with the raft path accepted a proxy group with no name.

Full meta:: (290) and raft:: (219) suites pass.

Base

Stacked on #231, which introduced admission_refusal. Merge #231 first.

It targets main rather than #231's branch on purpose: rust-ci and
oss-readiness declare pull_request: branches: [main, rust-main], and for
pull_request that filters the base. A pull request aimed anywhere else is
never compiled and its tests never run, while still reporting CLEAN.
Targeting main means this diff also carries #231's commit and CI builds the
two together, which is the state that will land; once #231 merges this reduces
to its own commit.