Say that a host's radius, temperature and luminosity come from the composite table alone

The comment on hostStarRadiusSolar and its two neighbours said they were read from "the planet's
default row first, then the composite table". The default-row query (TAP_COLUMNS in
fetchExoplanets.ts) asks for none of st_rad, st_teff or st_lum — the cached answer's columns end at
st_mass and disc_year — so host() always reads them from pscomppars, whose columns may each cite a
different reference: Proxima's 0.141 R☉ is the composite table's. It also said they were measured
where stellar.ts derives a luminosity, which held for the luminosity only once starSurfaceOf began
reading st_lum, earlier on this branch; it now points at starSurfaceOf. A comment, so there is no
test to fail.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

src/app/shared/models/exoplanet.model.ts

@@ -27,9 +27,10 @@ export interface ExoplanetRecord {
   hostStarMassSolar?: number;
   /**
    * The host's radius in solar radii (`st_rad`), effective temperature in kelvin (`st_teff`) and
-   * luminosity in solar luminosities (10^`st_lum`), where the archive gives them: the planet's
+   * luminosity in solar luminosities (10^`st_lum`), where the archive gives them: from the
-   * default row first, then the composite table, whose columns may each come from a different
+   * composite table (pscomppars) alone, since the default-row query does not ask for these three,
-   * reference. Measured, where `stellar.ts` otherwise derives a luminosity from V and distance.
+   * and each column of it may come from a different reference — Proxima's 0.141 R☉ is one.
+   * Preferred to what `stellar.ts` would derive; see `starSurfaceOf`.
    */
   hostStarRadiusSolar?: number;
   hostStarTemperatureK?: number;