FFS-3602: Add concept of "Reporting Month" to HR1 flow with date validation

[daphnegold]

Ticket

Resolves FFS-3602.

Changes

• Add reporting_month to ActivityFlow, ActivityFlowInvitation defaulting to current month
• Date validation to check if activities are in specified reporting month
• Job & volunteer activities now inherit from abstract Activity class
• Update UI to show "Reporting Month"
• Fix some missing content when adding an education activity
• Add date picker and field to job training activity
• Tests

Context for reviewers

There was some ambiguity around how we'd like to handle the date picker UI when there are multiple months vs one month, but I say let's defer that until the future when we have more solidified designs. This is a great starting point for the UI and validations.

While I added date concepts to the job training activity, it didn't really make sense to do anything with education activity at this point, given how it's processed.

Note that tokenized flows intake a reporting month during link creation and it is stored on the flow invitation. That invitation information is then copied over to the flow when the link is used.

Acceptance testing

• No acceptance testing needed
  • This change will not affect the user experience (bugfix, dependency updates, etc.)
• Acceptance testing prior to merge
  • This change can be verified visually via screenshots attached below or by sending a link to a local development environment to the acceptance tester
  • Acceptance testing should be done by design for visual changes, product for behavior/logic changes, or both for changes that impact both.
• Acceptance testing after merge
  • This change is hard to test locally, so we'll test it in the demo environment (deployed automatically after merge.)
  • Make sure to notify the team once this PR is merged so we don't inadvertently deploy the unaccepted change to production. (e.g. :alert: Deploy block! @ffs-eng I just merged PR [#123] and will be doing acceptance testing in demo - please don't deploy until I'm finished!)

[j-shilling]

Looks awesome to me

[j-shilling]

I wonder if using FactoryBot attributes_for / create would make these tests easier to refactor in the future. That would let us only need to update test where the new column is relevant to the assertions.

[j-shilling]

nit: I feel like make the assertion relative to the invitation is more semantically meaningful--just because we don't care about the date as much as we care about it matching what the input was.

Suggested change

	expect(flow.reporting_month).to eq(Date.new(2025, 3, 1))
	expect(flow.reporting_month).to eq(invitation.reporting_month)

[j-shilling]

ni: just like above this could use the method names to describe intention.

Suggested change

	flow = build(:activity_flow, reporting_month: Date.new(2025, 2, 1))
	expect(flow.reporting_month_range).to eq(Date.new(2025, 2, 1)..Date.new(2025, 2, 28))
	reporting_month = Date.new(2025, 2, 1)
	flow = build(:activity_flow, reporting_month: reporting month)
	expect(flow.reporting_month_range).to eq(reporting_month.beginning_of_month..reporting_month.end_of_month)