Star manifest samples teff/feh/radius unconditionally, regardless of data support

[jdeast]

Context

Star.register_parameters() always adds teff, feh, and radius as free,
sampled parameters (see the comment already flagging this at
src/exozippy/components/star/star.py:34-36: "these should require
evolutionary model, empirical relation, limb darkening, sed, or maybe
microlensing (baseline flux) but for now, we'll always initialize them").
In practice, every example config that lacks one of those data sources works
around it with a manual sigma: 0.0 hack in its params.yaml (see
examples/ob161003/ob161003.params.yaml).

Proposed rule

• feh: sample only if SED, evolutionary model (MIST/PARSEC), an empirical
  relation (Mann or Torres), a limb-darkening table lookup (TBD), or an
  explicit user prior is active/given for that star.
• teff: same list, but empirical relation is Torres-only — Mann's relation
  (massradius_mann.py) takes Ks magnitude + feh and never touches Teff.
• radius: sample only if transit, SED, evolutionary model, an empirical
  relation (either Mann or Torres — both output radius), a limb-darkening
  table lookup (TBD), finite-source microlensing (source stars only), or an
  explicit user prior is active/given for that star.

An explicit user prior (e.g. a spectroscopic Teff/feh measurement, or a
directly-imaged/interferometric radius) should always win — a star with no
qualifying component but a user-supplied sigma/mu on teff/feh/radius must
still be sampled, not silently fixed.

Verified against the physics: sed.py's BC-grid interpolation and the
teffsed/fbolsed floor priors, massradius_mann.py's actual signature, MIST's
inputs, and mulensing's calc_rho(radius, distance, theta_E) dependency all
confirm the above.

Known gaps to solve as part of this

1. Per-star-instance granularity is required, not system-wide. The
   existing in_system(component) check in star.py is a single yes/no for
   the whole system. But e.g. finite-source only floats radius for the
   SOURCE star(s), not the lens; SED already carries a per-instance
   staridx. A system-wide switch would incorrectly float/fix the wrong
   star in any multi-star system.
2. The existing mask convention is dead code. orbit.py and star.py
   already pass {"mask": ...} in a couple of manifest entries (hk_mask,
   age/initfeh), suggesting an intended mechanism for exactly problem Need help with test_ulens.py #1 —
   but Parameter.mask is never read anywhere in build_pymc or
   component.py::add_parameter. Either wire it up or replace it.
3. No rank-aware "default sigma" mechanism exists — this is what makes
   "or an explicit user prior" actually work. add_hint/add_scale_hint
   let a component propose a default initval/init_scale that yields to an
   explicit user override (via provenance rank). There's no equivalent for
   sigma — manifest options unconditionally overwrite cfg["sigma"]
   (full_params = {**cfg, **options}), so naively forcing sigma=0 in the
   manifest would silently clobber a user's explicit prior instead of
   yielding to it. Needs a mechanism that behaves like the hint system but
   for sigma, checked per star instance against config_manager.user_params
   before the star component defaults it to fixed.
4. evolutionary_model/mann/torres aren't real components yet.
   src/exozippy/evolutionary_model/massradius_mann.py and
   massradius_mist.py are unimported stub files (not under components/,
   not in physics_registry), so in_system('evolutionary_model') and
   in_system('mann') are dead conditions today. No Torres implementation
   exists at all. The gating logic can be written now; those branches just
   won't fire until those components are built.

Out of scope

• Actually building the evolutionary_model/Mann/Torres/LD-table components.
  This issue is scoped to the star-manifest gating logic and the two
  supporting mechanisms (microlensing parameters issue #2, MMEXOFAST Outputs #3 above), reachable today via SED and
  finite-source microlensing.