Self-assignable roles

A small but useful addition to the role system landed today. In the role editor, you'll see a new checkbox: Self-assignable.

Flip it on, and that role shows up on every member's own profile under "Available roles" with a checkbox. They tick it, they have the role. Instantly — no save bar, no admin approval.

That sounds dangerous, but it isn't. The role grants whatever you configured it to grant. If you want a purely cosmetic role — orange name color, a sparkle badge — that's what the member gets. If you've configured an opt-in "Beta tester" role to also unlock access to the #beta category (via a per-category override), great, they get that too. The flag just controls who can give it to themselves, not what it does.

Use cases that come up often:

• Color + badge preferences. Members pick their accent color from a curated set of opt-in roles. Each one's only differentiator is the color / badge fields. No permission impact.
• Hobby / interest groups. A "Photographers" role that's just for showing in member lists and the hover card. Maybe later you wire it up to a per-category permission so only photographers can post in #photo-share.
• Identity flags. "Newcomer", "Returning member", "Active developer". Members self-identify; the hover card surfaces it.
• Opt-in beta access. Wire it to a per-category override so the role grants posting in #beta, then flip self-assignable on. Members opt in, they're testing. Flip it off, the beta closes.

Owner is the one role you can't mark self-assignable. Self-assigning Owner would be a privilege-escalation footgun even with the new system's special-case handling. Transfer Ownership still goes through its own dedicated flow.

All assignments + revocations write audit rows with new event types so you can reconstruct who opted into what and when.