Alphabetize the Product Drive Participant drop-downs (#5593)

[pcbeingused333]

Part of #5593 — the two drop-downs named in the issue. The survey of every other drop-down in the app is posted as a comment on the issue, per @dorner's suggestion that its results inform a separate ticket.

What was wrong

ProductDriveParticipant.alphabetized ordered by contact_name, but every drop-down shows business_name and only falls back to contact_name when it is blank — so the lists were sorted on a column the user cannot see.

Sorting on the displayed name isn't enough on its own:

• ORDER BY name uses the database collation, which is not the same everywhere. A C.UTF-8 cluster (what bin/setup gave me for dev and test) puts every capitalised name before every lowercase one; the postgres:12.3 image CI runs is initialised with en_US.utf8 and doesn't. Same code, different list — and a test that pins the order can pass in CI while the user sees something else.
• Plain text ordering isn't natural: "Store 10" sorts before "Store 9", which the issue's completion criteria rules out.

product_drive_participants/create.js.erb rebuilt the drop-down without the ordering scope at all, so the new-donation list lost its order as soon as a participant was added from the modal.

The donation filter labelled its options with business_name alone, so participants who only have a contact name showed up as blank entries.

What changed

• NaturallySortable.natural_order builds an ORDER BY expression that lowercases the value and zero-pads runs of digits, so ordering is case-insensitive and natural regardless of the cluster's collation. It's an expression rather than a Postgres function or an ICU collation on purpose: the schema is maintained as schema.rb, which carries neither, so both would disappear on db:schema:load.
• alphabetized now sorts on COALESCE(NULLIF(business_name, ''), contact_name) — the value the user actually reads — through that expression.
• create.js.erb uses the scope again, and all three places label options with the existing display_name method, so the sort key and the label can't drift apart.

Verified

• New model specs cover both the fallback to contact name and "Store 2 / Store 9 / Store 10".
• bundle exec rspec spec/models/product_drive_participant_spec.rb spec/requests/donations_requests_spec.rb spec/requests/product_drive_participants_requests_spec.rb spec/system/donation_system_spec.rb spec/system/product_drive_participant_system_spec.rb, rubocop and erb_lint all pass locally.

[pcbeingused333]

Pushed a fix for the Brakeman failure — it was mine, and it had been red since I opened this.

NaturallySortable#natural_order interpolated its argument into Arel.sql, which Brakeman flags as SQL injection (Medium confidence). Rather than add the fingerprint to config/brakeman.ignore, I removed the cause: the expression is now a literal constant DISPLAY_NAME_ORDER on ProductDriveParticipant, with no interpolation, so nothing can carry a value in. The concern is gone — it only ever had one consumer, so it was an abstraction ahead of its need.

I also rebased onto current main, which clears a second Brakeman warning: this branch still carried Rails 8.0.2.1 and main is on 8.1.3.1.

Verified locally with Brakeman 8.0.5 — Security Warnings: 0, exit 0, same as main. The ordering behaviour is unchanged and the existing specs still cover both cases (fallback to contact_name, and "Store 2" / "Store 9" / "Store 10").

The workflows are currently showing action_required, so they'll need an approval to run.