Give every radio's settings editor the same tabs (#131)

.claude/skills/new-radio/SKILL.md

@@ -214,6 +214,11 @@ Then wire *both* ends, and check each off explicitly:
   (`src/components/profiles/ProfileEditor.tsx`) for a card radio
 - [ ] **`apply_settings` called by the export path**
 - [ ] the table↔schema agreement test
+- [ ] **every section names a `group`** — one of `SETTINGS_GROUPS` in
+      `src/lib/profiles.ts` (General, Display, Sounds, APRS…), so the radio's form
+      lands on the same tabs as every other radio's (#131). Keep the OEM's section
+      names as the labels; when an OEM section mixes subjects, give the odd field
+      its own `group`. `wiring.rs` refuses a missing or unknown one.
 
 - [ ] **the coverage check against step 1's menu census** — the schema's field
       count and groups reconciled against the menus the radio actually has, with

CONTRIBUTING.md

@@ -180,7 +180,9 @@ working.
 6. **Settings**, if the radio has them: put `SettingsReader`/`SettingsWriter` in
    `radios/<driver_key>/settings.rs`, and describe the fields in the model's
    `non_channel_settings_schema` JSON. That schema drives both the generic settings form and the
-   schema-driven write path — the fields do not need bespoke UI or a bespoke command.
+   schema-driven write path — the fields do not need bespoke UI or a bespoke command. Open the
+   schema with a `"section"` entry and give every section a `group` from `SETTINGS_GROUPS` in
+   `src/lib/profiles.ts`; that is the tab it is drawn on, the same tabs for every radio.
 
 7. **Frontend: usually nothing.** With `programming_ui: 'generic'`, the capability-driven dialog
    already offers identify, backup download, program, and verify. Only a radio needing genuinely