Link motions to agenda items in ExtractVotesJob

[AndreRobitaille]

Problem

`Motion` has a `belongs_to :agenda_item` association, but `ExtractVotesJob` never populates `agenda_item_id`. All motions currently have `agenda_item_id: nil`.

This means:

• Cannot trace votes to topics — the chain `Vote → Motion → AgendaItem → AgendaItemTopic → Topic` is broken, so we can't show "history of votes on a particular topic"
• Topic page "Key Decisions" section is empty for all topics — even topics with documented contracts and votes show "No votes or motions recorded." This is the biggest credibility gap on topic pages (see Topic page UI/UX overhaul — visual hierarchy, affordances, intuitiveness #63).
• Cannot show vote detail per agenda item — the meeting show page can't render database-backed vote grids per item

Why this matters now

The homepage redesign (Apr 10, 2026) creates a newspaper-style front page linking to topic pages. The topic page needs to be a credible landing page, but Key Decisions being empty for topics with clear votes (e.g., lead service lines has a $2.4M contract mentioned in its Record section but zero Key Decisions) makes the site look broken. This is the #1 blocker for making topic pages the primary homepage destination.

What Works Today

• `Vote → Motion → Meeting` — member votes per meeting ✓
• `Motion → Meeting → Committee` — which committee ✓
• `Vote → Member` — who voted how ✓

What Needs to Change

`ExtractVotesJob` (which calls `Ai::OpenAiService#extract_votes`) needs to:

1. Include agenda item context in the extraction prompt — pass agenda item IDs and titles alongside the minutes text so the AI can match motions to items
2. Return `agenda_item_id` in the structured response for each motion
3. Populate `Motion.agenda_item_id` when creating/updating motion records

The AI already reads minutes text that contains motion descriptions adjacent to agenda item discussions. The matching should be straightforward for most motions. Some motions (like consent agenda batch approvals) may not map cleanly to a single item — those can have `agenda_item_id: nil` and that's fine.

Enables

• Topic "Key Decisions" section (Topic page UI/UX overhaul — visual hierarchy, affordances, intuitiveness #63): Show votes related to a topic via `Topic → AgendaItemTopic → AgendaItem → Motion → Vote`
• Member voting record by topic: Group a member's votes by topic
• Inline vote breakdown on meeting page: Database-backed vote grids per agenda item

Backfill

After fixing `ExtractVotesJob`, re-run for all meetings with minutes to populate `agenda_item_id` on existing motions. The job is idempotent (uses `find_or_create_by`).

Not in Scope

• Topic page UI/UX changes (that's Topic page UI/UX overhaul — visual hierarchy, affordances, intuitiveness #63)
• Meeting show page redesign
• Member show page vote display improvements

[AndreRobitaille]

Shipped in merge commit ce68e4d.

ExtractVotesJob now passes agenda item context to the extract_votes AI prompt. The AI returns an agenda_item_ref per motion, and resolve_agenda_item matches those refs to real AgendaItem records (exact item number match first, then fuzzy title word-overlap with 0.5 threshold). Unmatched motions (consent agenda, procedural) keep agenda_item_id: nil.

Enables the Topic page Key Decisions section via Vote → Motion → AgendaItem → AgendaItemTopic → Topic.

Backfill still needed after next deploy — existing Motion records in production have agenda_item_id: nil. Run ExtractVotesJob for every meeting with minutes to populate historical rows:

Meeting.joins(:meeting_documents)
  .where(meeting_documents: { document_type: 'minutes_pdf' })
  .find_each { |m| ExtractVotesJob.perform_later(m.id) }

Tests: test/jobs/extract_votes_job_test.rb (8 tests).