Backfill contact_us_fyi communications as incoming, then drop the dual-condition checks

Context

In #2239 we extended the "needs response" concept from contact_us_fyi notifications to all incoming communications. Because existing contact_us_fyi rows are stored as direction: "outgoing", the code currently has to check both conditions:

• Notification#requires_response? — kind == "contact_us_fyi" || incoming?
• Notification.responded_status scope — where(kind: "contact_us_fyi").or(where(direction: "incoming")), and the "na" branch has to exclude both.

A contact_us_fyi is conceptually an incoming contact (the person reached out to us), so it should simply carry direction: "incoming". Once it does, the kind == "contact_us_fyi" half of every check is redundant and can go.

Work

1. Create new contact_us_fyi notifications as incoming. Update wherever they're generated (contact-form flow / NotificationServices) so direction: "incoming" is set on creation. Do this first — otherwise removing the OR breaks newly-created rows.
2. Backfill existing rows — a reversible data migration: Notification.where(kind: "contact_us_fyi", direction: "outgoing").update_all(direction: "incoming") (guard the down).
3. Simplify the code once every contact_us_fyi is incoming:
   • requires_response? → incoming?
   • responded_status → key off direction: "incoming" only:
     • "yes" → where(direction: "incoming", responded: true)
     • "no" → where(direction: "incoming", responded: false)
     • "na" → where.not(direction: "incoming")
4. Update specs in spec/models/notification_spec.rb (the .responded_status and #requires_response? groups) to reflect the single-condition logic.

Notes

• Sanity-check that no contact_us_fyi should legitimately be outgoing before backfilling.
• Files: app/models/notification.rb, plus the contact-form/notification-creation path.

Start with app/models/notification.rb, the contact-form/NotificationServices creation path, and the .responded_status and #requires_response? specs in spec/models/notification_spec.rb. Add the reversible backfill migration after confirming contact_us_fyi rows should be incoming, update creation and conditions, then run the notification specs and verify the migration’s down path is guarded.