Stop marking additional service areas as primary on registration

[maebeale]

What is the goal of this PR and why is this important?

• Registrants were ending up with multiple primary service-area sectors, which violates the "one primary" rule and crowns every sector on the person/recipients profile.
• Root cause: public registration fed both the single-select "Primary service area" dropdown (primary_service_area_single) and the multi-select "Additional service areas" checkboxes (primary_service_area) into one assignment that set is_primary: true on all of them.

How did you approach the change?

• Only the dropdown selection is marked primary; the checkbox selections become additional (is_primary: false).
• A sector named in both is kept as a single primary row (no duplicate), and any previously-primary sector is demoted so exactly one primary survives.
• Renamed assign_primary_sectors → assign_sectors to reflect that it now assigns both primary and additional.

UI Testing Checklist

• Register via the public form picking one primary + several additional service areas; confirm the person shows exactly one starred/primary sector and the rest as additional.
• Re-register naming a different primary; confirm the old primary demotes to additional.

Anything else to add?

• The existing specs encoded the bug (submitted the additional field and asserted is_primary: true); rewritten to assert correct behavior, plus added cases for one-primary, no-duplicate, and demotion. Full service spec green (23 examples).
• Per-person uniqueness (sector-to-person, category-to-person) is already enforced by DB unique indexes, so a sector can't be both primary and additional for one person — this fix addresses the primary-vs-additional mislabeling that produced the duplicate primaries.