security(cr): writable selected_field bypasses CR conflict checks

[gonzalesedwin1123]

Summary

Conflict and duplicate detection in spp_change_request_v2 scoped field-level
checks using a user-writable label. selected_field_name is only
view/model-readonly (not server write-protection) and group_cr_user has
write on their own spp.change.request. So a user could create a CR blocked by
a field-scoped conflict rule, then RPC-write the label to a field NOT in the
rule's conflict_fields; the check re-runs, returns empty, conflict_status
resets to none, and the CR submits/approves without the configured override
path. _calculate_similarity (duplicate detection) had the identical flaw.

Fix

Scope field-level conflict/duplicate detection to the fields that actually
differ from the registrant — the exact set the field_mapping apply strategy
will write — derived server-side, not from any declared label:

• New _proposed_changed_fields() on the conflict mixin: for use_dynamic_approval
  CR types, returns the mapped detail fields whose value differs from the
  registrant (via apply_mapping_ids); None for non-dynamic types (full
  configured field set always used — their details aren't registrant-prefilled).
• _filter_by_field_conflicts and _calculate_similarity scope to that diff.
• Neither selected_field_name nor the detail's field_to_modify is trusted
  for the security decision.

Why not just "derive from field_to_modify"

The first iteration derived the field from detail.field_to_modify instead of
selected_field_name. A two-reviewer staff review caught that this was still
bypassable: field_to_modify is also user-writable, and — crucially — it
does not constrain apply. field_mapping.apply writes every mapped field that
differs from the registrant, so write({'field_to_modify': 'phone', 'given_name': 'X'}) cleared the given_name conflict while still applying the given_name
change. Deriving from the actual diff (this version) makes both writable labels
irrelevant.

Testing

• ./spp t spp_change_request_v2 → 339 passed, 0 failed, 0 errors (5 new).
• New tests: writing selected_field_name cannot clear a field-scoped conflict
  (dynamic and static types) or drop duplicate similarity; mislabeling
  field_to_modify while actually changing a conflict field cannot bypass
  detection (own-side and candidate-side). Each fails against the pre-fix code.
• Added apply_mapping_ids to the dynamic test CR type (a field_mapping type
  requires them; the fixture had omitted them).

Scope / follow-ups

• Filed security(spp_change_request_v2): writable selected_field_name can steer dynamic-approval routing [Severity: Medium] #344 (Medium): the same writable selected_field_name also steers
  dynamic-approval routing (_resolve_dynamic_approval → CEL). Out of scope
  for this conflict-detection fix; best fixed by hardening the field's
  writability, coordinated with security(cr): route and apply the same single field for dynamic approvals #264.
• Overlap with security(cr): route and apply the same single field for dynamic approvals #264 (cr-dynamic-approval-field): it freezes these fields
  post-submit; this attack is in draft. Confined to conflict_mixin.py to
  avoid a write() collision with security(cr): route and apply the same single field for dynamic approvals #264. Version 19.0.3.0.3 (above security(cr): add record rules to CR detail models (ownership + area) #261's
  .0.2 and security(cr): route and apply the same single field for dynamic approvals #264's .0.1); trivial re-merge expected for whichever merges
  second. No migration.
• README generated files applied from CI's pinned oca-gen verbatim.

Draft: awaiting human security review before undraft/merge.

Merge order (CR security cluster)

Per the cross-PR interaction analysis (2026-07-24, internal/plans/security-prs-interaction-analysis.md), hard order: #264 → #261 → #338 → #343 (this PR, last).

• Merge only after the other three; re-merge this branch after each sibling lands (metadata-only conflicts on spp_change_request_v2 manifest/HISTORY/README).
• Final rebase must fix one docstring: _proposed_changed_fields claims the derived set is "exactly the set the field_mapping apply strategy will write" — once security(cr): route and apply the same single field for dynamic approvals #264 lands, apply writes only the selected field's mapping, so the derived set is a superset. One-line comment fix.
• Related follow-up filed: security(spp_change_request_v2): free diff-padding evades duplicate detection once #264 and #343 both land [Severity: Low-Medium] #346 (duplicate-similarity padding evasion created by the security(cr): route and apply the same single field for dynamic approvals #264+security(cr): writable selected_field bypasses CR conflict checks #343 combination; coordinate with security(spp_change_request_v2): writable selected_field_name can steer dynamic-approval routing [Severity: Medium] #344).

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[codecov]

Codecov Report

❌ Patch coverage is 91.83673% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.33%. Comparing base (1caf794) to head (d38ae99).
⚠️ Report is 3 commits behind head on 19.0.

Files with missing lines	Patch %	Lines
spp_change_request_v2/models/conflict_mixin.py	91.83%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             19.0     #343      +/-   ##
==========================================
- Coverage   74.28%   70.33%   -3.95%     
==========================================
  Files         372      205     -167     
  Lines       25385    17911    -7474     
==========================================
- Hits        18857    12598    -6259     
+ Misses       6528     5313    -1215     

Flag	Coverage Δ
spp_analytics	?
spp_api_v2_change_request	66.53% <ø> (?)
spp_api_v2_cycles	?
spp_api_v2_entitlements	?
spp_api_v2_gis	?
spp_api_v2_programs	?
spp_api_v2_simulation	?
spp_audit_programs	?
spp_base_common	91.07% <ø> (+0.80%)	⬆️
spp_case_demo	?
spp_case_entitlements	?
spp_case_programs	?
spp_change_request_v2	77.97% <91.83%> (?)
spp_cr_type_assign_program	92.07% <ø> (+0.90%)	⬆️
spp_dci_compliance	?
spp_dci_demo	94.28% <ø> (+0.88%)	⬆️
spp_dci_server_social	?
spp_demo	?
spp_demo_phl_luzon	?
spp_drims	?
spp_drims_sl	?
spp_drims_sl_demo	?
spp_farmer_registry_cr	61.24% <ø> (?)
spp_farmer_registry_demo	61.06% <ø> (+0.04%)	⬆️
spp_gis_report	?
spp_grm_demo	?
spp_indicator	?
spp_indicator_studio	?
spp_metric_service	?
spp_mis_demo_v2	70.99% <ø> (+0.03%)	⬆️
spp_programs	65.27% <ø> (+<0.01%)	⬆️
spp_registry	86.94% <ø> (+0.10%)	⬆️
spp_security	69.56% <ø> (+2.89%)	⬆️
spp_simulation	?
spp_starter_sp_mis	86.66% <ø> (?)
spp_studio_change_requests	84.85% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
spp_change_request_v2/models/conflict_mixin.py	90.27% <91.83%> (ø)

... and 334 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gonzalesedwin1123]

Filed the related dynamic-approval routing bypass (same writable selected_field_name, different sink) as #344 — out of scope for this conflict-detection PR.

[gonzalesedwin1123]

Follow-up filed: #346 — once this PR and #264 both land, the duplicate-similarity exact-set-equality check becomes evadable via free diff-padding (#264 makes the padding side-effect-less). Conflict detection is not affected. Coordinate with #344.