Improve Badge Utilization by Clarifying Backend Frontend Coordination and Automation

### Context

OWASP Nest already includes a badge system as part of user profiles, with support implemented across both the backend and frontend. From a technical standpoint, the system is in place; however, badges do not yet feel fully utilized from a product or UX perspective.

While reviewing the codebase and UI, it appears that this is mainly due to:
- unclear coordination between backend and frontend expectations
- limited visibility into how automated badge assignment and unassignment are intended to work

This issue is meant to document those gaps and explore possible next steps.

---

### Current State

#### Backend
- Badges are defined via the `Badge` model and associated with users through `UserBadge`
- Badge assignment and revocation are handled via management commands, using eligibility-based sync logic and soft deactivation (`is_active`)
- User badges and badge counts are exposed through GraphQL
- Search and indexing include `idx_badge_count` for users

#### Frontend
- User profiles support rendering badge lists with icons and tooltips
- User listings and search results display badge counts
- Badge UI components, icon mappings, and mock data are already present

Overall, the badge system functions end-to-end from a data and API perspective.

---

### Observed Issues

Despite the existing implementation, several factors make badges feel underutilized or unclear:

1. **Unclear Automation Behavior**
- Badge assignment and unassignment rely on management commands
- There is no clear documentation describing when or how these commands are expected to run
(manual execution, scheduled jobs, CI tasks, etc.)
- This makes it difficult to reason about badge freshness and update timing

2. **Implicit Badge Lifecycle**
- There is no single, documented flow explaining:
- how badges are created
- how user eligibility is evaluated
- when and why badges are revoked
- Understanding the lifecycle currently requires reading and correlating multiple parts of the codebase

3. **Backend–Frontend Coordination Gaps**
- The frontend correctly consumes badge data, but lacks guidance on:
- whether badges represent roles, achievements, or both
- how prominently badges should be surfaced across pages
- As a result, badges tend to appear more decorative than informative, rather than acting as clear role or trust indicators

---

### Why This Matters

Because the badge lifecycle and automation strategy are implicit, badges can appear incomplete or unreliable even though the underlying system exists and works.

This limits how confidently contributors, maintainers, and frontend components can rely on badges as meaningful signals of user roles or contributions.

Improving clarity here would significantly increase badge usefulness without requiring major architectural changes.

---

### Proposed Direction

This issue is intended as a starting point to explore and clarify:

- the intended end-to-end badge lifecycle
- how automated badge assignment and unassignment commands are expected to run
- clearer backend–frontend expectations around badge meaning, freshness, and visibility
- whether any small, targeted improvements are needed after alignment

I’m happy to help further based on maintainer feedback.