Registry data model: bridge API-sourced gender_char to spp_registry gender_id, or document it as a separate raw-source field

[gonzalesedwin1123]

Context

Found during the spp_attendance migration review (PR #435, emjay0921's pass). This is a registry data-model question, not an spp_attendance defect — filed separately from the API-alignment follow-ups in #434 on the reviewer's suggestion.

The split

Two unbridged representations of gender exist on res.partner:

• spp_registry models gender as gender_id = fields.Many2one(...) (spp_registry/models/individual.py:32) and includes gender_id in the demographic_fields set used for eligibility.
• spp_attendance declares gender_char = fields.Char() on res.partner (spp_attendance/models/res_partner.py) and stamps it from API-sourced subscriber data.

Nothing maps one onto the other. A subscriber created through the attendance API ends up with gender_char set and gender_id empty — invisible to registry-side eligibility even when the source system supplied a perfectly good value.

PR #435 removed the previous fabricated "Male" default (gender is no longer invented when the source omits it), which made this pre-existing split easier to see; it did not cause it.

The question

Should API-sourced gender map onto gender_id, or is gender_char deliberately a separate raw-source field?

• If it should map: needs a resolution step (match/create against the gender vocabulary, with a policy for unrecognized source values — keep raw in gender_char and resolve what's resolvable?).
• If deliberately separate: the design intent should be documented on the field, and anything consuming attendance subscribers for eligibility needs to know registry demographics are not populated by that path.

Suggested owner per the review discussion: @jeremi (registry data-model call).