fix(farmer_registry_demo): Input Subsidy uses manual entitlement approval

[emjay0921]

Why is this change needed?

OP#1122 — Farmer demo data: modify at least one program to not tick auto-approve entitlements. Test pass.

Every demo program auto-approved its entitlements, so a demo could only ever show the cycle-approval stage. The entitlement-approval stage — a real part of the workflow — had nothing to demonstrate it with.

How was the change implemented?

• farmer_demo_generator no longer hard-codes auto_approve_entitlements: True. It reads the flag from the program definition and falls back to True, so every existing demo program is unchanged.
• Input Subsidy opts out. Its cycles still go through cycle approval, so a demo can now walk the full cycle → entitlement-approval chain rather than stopping at the first stage.

Scoped deliberately to one program: the point is to have an example of each behaviour side by side, not to change the default.

New unit tests

Added to spp_farmer_registry_demo/tests/test_demo_generator.py: Input Subsidy generates with auto_approve_entitlements off, and the other demo programs still generate with it on.

Unit tests executed by the author

Re-run after merging 19.0 up (the branch was 64 commits behind):

spp_farmer_registry_demo    0 failed, 0 error(s) of 135 tests

How to test manually

1. Install / regenerate the farmer demo data.
2. Open Programs → Input Subsidy and confirm Auto-approve entitlements is not ticked.
3. Open any other demo program and confirm it still is.
4. Run a cycle on Input Subsidy through to entitlements: the entitlements must land awaiting approval rather than approved, so the approval stage can be demonstrated.

Related links

https://openspp.openproject.com/work_packages/1122

Reviewer notes

The branch was 64 commits behind 19.0 and has been brought up to date by merging, not rebasing, since it was already published — hence the merge commit.

It also carries a readme/HISTORY.md entry and a version bump made when the branch was first written. That predates the convention of keeping those on the main branch after merge; left as-is rather than rewriting published history, but happy to strip them if you would prefer.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 71.50%. Comparing base (c33d3cb) to head (e70aaa8).

Additional details and impacted files

@@           Coverage Diff           @@
##             19.0     #412   +/-   ##
=======================================
  Coverage   71.49%   71.50%           
=======================================
  Files         243      243           
  Lines       20785    20790    +5     
=======================================
+ Hits        14860    14865    +5     
  Misses       5925     5925           

Flag	Coverage Δ
spp_base_common	91.07% <ø> (ø)
spp_farmer_registry_demo	61.06% <ø> (ø)
spp_programs	65.27% <ø> (ø)
spp_registry	87.22% <ø> (+0.07%)	⬆️
spp_security	69.56% <ø> (ø)

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

Files with missing lines	Coverage Δ
spp_farmer_registry_demo/models/demo_programs.py	100.00% <ø> (ø)
...rmer_registry_demo/models/farmer_demo_generator.py	50.14% <ø> (ø)

... and 1 file 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]

Approved — this is exactly the shape these changes should take.

The substance is five lines: the generator reads auto_approve_entitlements from the program definition (defaulting True) and Input Subsidy opts out. What made this easy to approve:

• Full versioning treatment: bump to 19.0.2.1.2 with readme/HISTORY.md, the README changelog, and the regenerated HTML description.
• The changelog's subtle claim is true — I verified it: Step 4b of the seeded-cycle walk (farmer_demo_generator.py:2368) force-approves draft/pending entitlements on every generated cycle regardless of this flag, so seeded demo data is unchanged and the manual-approval behaviour surfaces exactly where the PR says it does: on cycles a demo user runs afterwards.
• Tests assert through the real chain (wizard → program → cycle manager), a control program pins the default, and the invariant test ("at least one manual program exists") protects the ticket's intent against future edits to the definitions.

Three notes, none blocking:

1. Version ordering with #322 — same module, both open. This PR takes 19.0.2.1.2, so #322's requested bump becomes 19.0.2.1.3 on top (or the reverse if #322 lands first). Code and test edits are in different regions, so it's purely a version/HISTORY reconciliation for whichever merges second.
2. On the reviewer note offering to strip the bump/HISTORY: please keep them. Per-PR version bumps on released modules are what the repo convention asks for (and what #441 proposes to enforce) — this PR is the model, not the exception.
3. Optional: because Step 4b force-approves seeded cycles, the demo ships with zero pending entitlements out of the box — demonstrating the approval stage requires running a fresh Input Subsidy cycle (as your manual steps describe). If you want the stage visible immediately after generation, seeding the newest Input Subsidy cycle with its entitlements left pending would do it. Fine as a follow-up or not at all; the ticket is satisfied as-is.