JM: Reach the person history through records that hang off a person

[maebeale]

🤖 suggested review level: 3 Read 📖 contained: ten resource types added to one query service, no schema change

Part of #2251.

Reach, not tracking

AhoyTrackable already covers every model, so a person's history isn't missing events — it's missing routes to them. Analytics::PersonActivityEvents maps person → ids per resource_type, and records that connect to a person only through a parent were absent from that map.

Nothing needs backfilling: the mapping is read-time, so it covers everything already recorded.

Ten types added

• Registration children — EventRegistrationChecklistCompletion, EventRegistrationOrganization, EventAttendanceTimeEntry
• Staffing — EventStaff
• Money — Allocation (through registration / CE registration / membership invoice), Refund (recipient, or reversing one of their payments), MembershipInvoice
• Forms — FormAnswer, plus the Asset uploads those answers own
• Scholarships — ScholarshipAgreementResponse

Repeated subqueries (registration / submission / payment / scholarship ids) are memoized rather than rebuilt inline.

How to test

1. ai/server, sign in as an admin.
2. Act on something that reaches a person through a registration — add a payment/allocation, tick an onboarding checklist step, upload a form answer file.
3. Open /people/:id/edit → Associated records → History, or /admin/activities/events?person_id=:id&time_period=all_time&audience[]=visitors&audience[]=users&audience[]=staff.
4. Look at the Activity column for create.allocation, update.event_registration_checklist_completion, create.form_answer, create.asset. On main none of those can reach a person's history no matter how many exist.

Scope: all ten, decided

Keeping the full set, including the mechanical ones (create.allocation, update.event_registration_checklist_completion, update.event_attendance_time_entry). The history is meant to be complete; filtering for readability belongs in the UI, not in what reaches the page.

Note on the approach

This reaches the records at read time — the relation is an OR of ~33 subqueries, bounded per person. #2251 sketches a denormalized tag table instead; that's a different mechanism for a wider problem (event and organization timelines), and not a blocker here.

[maebeale]

🤖 From Claude: Scope decided — keeping all ten resource types rather than trimming to the money/forms subset. Completeness over scannability; filtering belongs in the UI. The read-time traversal question against #2251 is still open.