Three independent feature flags, all default OFF pending live A/B
backtest (no DB access in worker/main sessions this round — see PR
body for exact before/after commands to run once available):
- estimate_kitchen_area_signal_enabled / estimate_ceiling_height_signal_enabled:
house_type/year_built have a user-input target to compare candidates
against; kitchen_area_m2/ceiling_height_m have neither a target
(TradeInEstimateInput doesn't collect them) nor ground-truth on
rosreestr deals (backtest DealSample lacks these columns). Inventing
an external "typical" constant would be unfounded, so the penalty is
self-referential: deviation from the CANDIDATE POOL's own median in
Tier H/W relevance_score. NULL-safe (no penalty, excluded from
median) and sparse-safe (fully skipped when <5 non-null values in
the pool).
- estimate_is_apartments_filter_enabled: hard-filter in _COMMON_WHERE +
Tier W, symmetric to the existing novostroyki-guard (#1186). NULL
passes through untouched, only explicit true excluded.
Review fixup: _stratify_candidates requires its input pre-sorted by
relevance_score (its per-source guaranteed-quota selection depends on
that order). _apply_kitchen_ceiling_signal mutates relevance_score
in-place after the SQL fetch but before stratify — added an explicit
re-sort in both call sites (Tier H, Tier W) so the diversity-quota
selection sees the post-adjustment order once either flag ships live.
Currently a no-op (flags off), but was a latent footgun for the first
PR to flip one on.
