Prefer keyword arguments over option-hash parameters in app code #3009

What

Adopt keyword arguments over default-valued positional parameters for new and touched methods, where the parameter is meant to be a set of named optional values.

Why

The kwargs form is what the latest review (PR #3003, release_seat) settled on; call sites read the same, and a misspelled key raises ActiveRecord::UnknownAttributeError instead of passing silently.

Where the old pattern remains

These are candidates, none urgent; convert opportunistically when each file is next touched:

1. app/queries/sponsors_search.rb:6 — def initialize(params = {}) with params.fetch inside. Call sites: SponsorsSearch.new(search_params) from admin/sponsors_controller.rb:9. Convertible to def initialize(name:, chapter:); search_params already builds exactly { name: ..., chapter: ... }.
2. lib/verifier.rb:6 — def initialize(hash) with hash.fetch. Call sites already use kwargs: Verifier.new(id: ...) (helpers), Verifier.new(token:) (controller). Ruby 3 separates kwargs from positional hashes, so a hash literal would raise ArgumentError — kwargs are already the de facto contract; the signature just does not say so.
3. app/controllers/admin/{meetings,events,workshops}_controller.rb — def grant_organiser_access(organiser_ids = []). The default is unused (all four call sites pass the argument), so this is about dropping the dead default rather than kwargs; a two-step refactor (drop default, then review whether the trio should be a shared concern).

Excluded (intentionally unchanged)

• def number_to_currency(number, options = {}) in application_helper.rb — wraps a Rails stdlib method whose signature is a positional options hash; matching the stdlib shape is correct.
• title(title = nil), avatar(size = 100), sponsors?(level = nil) — optional scalar values, no kwargs involved.

Method used

ast-grep pattern def $_($A = $B) over app/ and lib/ to find default-valued params, then manual classification of each hit.