security(cr): add record rules to farmer-registry & studio CR detail models (deferred from #261)

[gonzalesedwin1123]

Follow-up to #261 (CR detail-model record rules). #261 closed the missing-ir.rule gap for spp_change_request_v2's detail models (and spp_cr_type_assign_program). Two other modules share the same vulnerability class but use different group models, so they need per-module ownership analysis rather than a copy of the CR rule.

Affected models

• spp_farmer_registry_cr — spp.cr.detail.farm_details, manage_farm_activity, manage_farm_asset, manage_land_parcel. ACL grants spp_registry.group_registry_officer full r/w/c/unlink and group_registry_read read; no ir.rule.
• spp_studio_change_requests — spp.cr.detail.generic. ACL grants spp_studio.group_studio_editor_officer r/w/c, viewer read, manager all; no ir.rule.

Without rules, a low-privilege holder of those groups can read/write detail rows of change requests they do not own, via direct RPC (the same bypass #261 fixed).

Open question (must answer before writing rules)

Is a registry_officer / studio_editor meant to be trusted broadly (like a CR validator → [(1, '=', 1)]), or scoped to their own / related CRs? Getting this wrong either breaks legitimate officer workflows or leaves the hole open. This is why it was split out of #261 rather than copied.

Proposed work

1. Decide the trust model per group (broad vs owner-scoped).
2. Add ownership + area ir.rules accordingly (pattern per security(cr): add record rules to CR detail models (ownership + area) #261, but domains depend on each module's parent-link fields).
3. Extend a completeness sweep (like test_every_concrete_detail_model_is_fully_scoped) into these modules with their own group models.

Source: internal/plans/sec-cr-detail-record-rules.md ("Deferred to a SEPARATE follow-up").