feat(roles): seed default group bindings to match test personas

[larsgeorge-db]

Summary

Follow-up to #459 (runtime test-user impersonation). Until now only the Admin role shipped with a default assigned_groups binding (driven by APP_ADMIN_DEFAULT_GROUPS). All other seeded roles were created with empty assigned_groups, so the runtime persona override would correctly impersonate the persona's identity but resolve to zero permissions — making the feature useless out of the box for anything except the Admin persona.

This patch bakes the conventional group names into both seed sources so every persona in src/backend/src/data/test_personas.yaml lands in the matching role on first run.

Bindings added

Role	assigned_groups
Data Governance Officer	data-governance-officers
Data Steward	data-stewards
Data Producer	data-producers
Data Consumer	data-consumers
Security Officer	security-officers

Group names match the personas in test_personas.yaml and the labels in the Test Persona dropdown.

Sources touched

• src/backend/src/data/settings.yaml — the authoritative seed YAML.
• DEFAULT_ROLES in src/backend/src/controller/settings_manager.py — the in-code fallback used when the YAML is missing. Also updated the generated_roles codepath that writes the YAML on first run, so a fresh deployment without settings.yaml also gets the bindings.

Why Admin is intentionally NOT touched

Admin's assigned_groups continue to come from APP_ADMIN_DEFAULT_GROUPS. Hardcoding it here would risk granting admin to whatever happens to be set on someone's local workspace by name collision. Production deployments keep explicit control via env var.

Migration

Existing deployments already have role records persisted to the database and will not be affected by this change (the seed only fires when records are missing). To pick up the new bindings on an existing install:

• Recommended: Settings → Roles → edit each role → add the corresponding group from the table above.
• Or: delete the affected role rows so they get re-seeded on next start.

Test plan

• Fresh install (empty DB, no settings.yaml): role records pick up the new groups.
• Fresh install (with shipped settings.yaml): role records pick up the new groups.
• Existing install: role records remain unchanged (verifies we're not destructive).
• With TEST_USER_TOKEN set: pick "Data Producer" from the Test Persona dropdown -> /api/user/permissions returns Producer's permission map (non-empty), not None across the board.