Build a reward configuration system

[marcuscollins]

We are starting to have lots of different kinds of rewards (see PRs 324, 313, 319). I would like us to develop a configuration system so that we can choose rewards and in the future combine them. Minimally, a configuration should look like:

real_space_density:
    weight: 0.4
    reward_options:
        some_option: "good"
some_other_reward:
    weight: 0.6
    reward_options:
        option_1: 10
        option_2: "yay"

(YAML not required, could be JSON, something else)

[manzuoni-astera]

Had a go at this over the last day: #373, #374, #375. All three are up as drafts, since a few
things below are worth agreeing on before anyone spends review time on them.

The shape: each reward declares its options once as a frozen dataclass and registers a builder.
The CLI flags, the config-file schema, the validation messages and the run metadata all come off
that one declaration, so adding a reward type is a schema plus one registry entry. No argparse
plumbing to edit, no if/elif on reward type anywhere.

Two ways to configure a run, one structure underneath:

sampleworks-guidance ... --reward-type structure_factor --mtzfile 1vme.mtz --bulk-solvent combined
sampleworks-guidance ... --reward-config rewards.yaml   # the mapping from this issue

Both produce the same RewardConfig, and the file is the only way to combine rewards. Weights
are 1/N when none are given, verbatim when all are, and an error when only some are. A single
reward at full weight is built and returned directly, so runs going on right now keep the
gradients they have today. The default is still real_space_density with the same flag
spellings, so nothing anyone has typed before stops working.

Marcus, this picks up most of your #319 review: reward names are a StrEnum, weights come from a
configuration rather than a flag per reward, dispatch is uniform, missing-input errors live in
the reward functions, and prepare() returns None. I didn't touch #319 itself and I'm not
asking anyone to redo work there. It rebases down to the reward class, an options dataclass and
one registry entry.

One thing worth knowing regardless of any of this: the structure-factor reward from #324 was
unreachable. Nothing in src/ ever called its prepare(), so it could not run from a guidance
job at all. #373 fixes that on its own and is worth landing even if the rest gets argued about.

Three things I'd rather decide together than guess at:

• Sign convention (Rewrite the LatentAnchor and Geometry Penalty into reward. #363). Rewards are minimized, since guidance backprops the value and FK
  steering takes argmin. That's in the protocol docstring now and the contract tests enforce it,
  which means the geometry term in feat(it-opt): per step latent space optimization #313 has to flip. Renaming RewardFunctionProtocol to
  something honest is churn against three in-flight PRs, so I left the name alone.
• Grid search. Still density-only. The proteins CSV is structure,density,resolution, and
  structure factors need it to carry an MTZ. RewardConfig.with_experimental_data() is the hook
  when we want it.
• feat(rewards): add torchref-backed reciprocal-space x-ray reward #372's refresh_nuisance_parameters(). It refits every N calls, but under FK steering
  __call__ fires several times per denoising step, so an internal counter refreshes at the
  wrong cadence. Probably wants a second optional hook rather than each reward inventing one.

The PRs are stacked (#374 and #375 include the commits below them, and each says where to start
reading). Happy to walk through any of it, or to cut it differently if the split is awkward.