spp_studio: 25 of 27 field-backed standard variables point at fields that exist on no model

[emjay0921]

Problem

spp_studio/data/standard_variables.xml ships spp.cel.variable records whose source_field names a field that exists on no model. Studio's variable picker therefore advertises these to no-code users, and any filter, formula or scoring expression built on one cannot translate or evaluate — the same failure mode as #431, reached from the UI instead of from shipped pack data.

#431 and #444 dealt with the 24 shipped pack items that consumed these variables. The variables themselves are still shipped, so the defect class is still reachable.

Evidence

Of the 27 source_type="field" variables in standard_variables.xml, 25 have a source_field that is not defined anywhere. Two independent checks:

1. An index of every <name> = fields.<Type> definition in this repo (2,837 field names) plus base's res_partner.py — 25 of the 27 source_field values are absent from it.
2. ir_model_fields on a dev database, sampled:

source_field	on res.partner?
in_institutional_care	exists
is_legal_resident	absent
is_food_insecure	absent
is_orphan	absent
land_hectares	absent
owns_car	absent
is_person_with_disability	absent
residency_years	absent

The full orphan list from check 1:

var_residency_years, var_has_disability, var_disability_certified, var_disability_percentage, var_requires_caregiver, var_has_formal_pension, var_formal_pension_amount, var_is_orphan, var_is_double_orphan, var_is_in_education, var_education_years_head, var_is_single_parent, var_formal_income, var_can_perform_manual_labor, var_eligible_for_light_duty, var_is_enrolled_in_school, var_has_enrollment_exemption, var_liquid_assets, var_non_housing_assets, var_owns_car, var_motorcycle_count, var_current_pw_participants, var_is_skipped_generation, var_is_legal_resident, var_land_hectares

Caveat on the count: check 1's index covers this repository plus base.res_partner. A field defined in another addon on the deployment's addons path would show as a false orphan, so treat 25 as indicative and re-verify per item before acting. The sampled eight in check 2 are confirmed against a real installed schema.

Why this matters

in_institutional_care in #444 is the instructive counter-example: the field existed in spp_registry and only the variable was missing, so adding the variable made the shipped expression work. These 25 are the mirror image — the variable exists and the field does not — and that is the case that leaves a no-code user with a variable they can select but never evaluate.

Possible directions

Per variable, one of:

1. Back it with a real field where the concept belongs in the registry (as in_institutional_care already is).
2. Remove the variable where the concept is not part of the platform's data model.
3. Repoint source_field where an equivalent field exists under a different name (e.g. var_has_disability → is_person_with_disability is already a rename attempt; check what spp_disability_registry actually defines).

A guard test would stop this recurring: assert that every source_type="field" variable's source_field resolves in env[source_model]._fields. spp_cel_load_testing's TestStudioVariableValidation is the natural home — it currently parses cel_accessor values but never checks that a field-backed variable's field exists.

Context

Found while reviewing #444 (which fixes #431). Not a regression from either — both predate them.