Scholarship agreement log: settle removal vs keep before dropping the table

🤖 From Claude:

Part of #2251. Carved out of that umbrella's follow-ups, which scoped this as: backfill any needed history from scholarship_agreement_responses, then drop the callbacks, the _agreement_history partial, and the table.

Blocked by #2351.

Why it isn't a straight removal

The removal assumed a generic change log (PaperTrail versions at the time; Ahoy events now that #2245 pivoted) covers what the bespoke log holds. It doesn't:

Scholarship#latest_agreement_response is a live read dependency: the responded-at date and decline reason are not columns on scholarship, so the UI has no other source.

Worse, per #2351 a logged-out recipient accepting or declining on the public callout produces no Ahoy event at all — the bespoke log is currently the only record that it happened.

Current surface

• Scholarship: has_many :agreement_responses, after_create/after_update :log_agreement_response, latest_agreement_response
• app/views/scholarships/_agreement_history.html.erb, rendered by scholarships/edit and events/callouts/scholarship (admin-styled)
• ScholarshipAgreementResponse + scholarship_agreement_responses table
• Specs: scholarship_agreement_response_spec, plus agreement-history coverage in scholarship_spec and events/callouts_spec

Recommendation

Keep the table; treat the follow-up as de-duplicating the UI, not deleting the log.

1. Fix #2351 first, so recipient responses are tracked at all.
2. Decide where reason / responder / point-in-time amount_cents live if the table goes. If the answer is "on the scholarship", that's a schema change plus a backfill — bigger than the removal it was meant to simplify.
3. If the goal is just "one history UI per record", drop _agreement_history in favour of the shared activity log only once the generic log carries those fields.

Acceptance

Either a decision recorded here to keep the table (and the duplicate-UI question settled), or a plan that names the new home for every field in the table above, with a backfill.

Start with #2351, then inspect Scholarship, ScholarshipAgreementResponse, app/views/scholarships/_agreement_history.html.erb, and the listed specs to understand the current log and UI dependencies. Done means recording a decision to keep the table and settle the duplicate UI question, or naming a new home for every field with a backfill plan.