Add reverification campaigns with cohort filters and no historical override bypass

[HunteRoi]

Summary

Implement reverification campaigns that allow admins to target cohorts of users for re-verification, while ensuring that historical manual overrides do not grant permanent bypass.

Problem

The specification requires global one-time verification, but it also requires admins to be able to force reverification later.

This creates an important rule:

• a past successful verification does not always remain sufficient forever
• a past manual override does not create a permanent exemption
• reverification must be targetable to cohorts, not only individual users

Without this feature, the verification model cannot be corrected, refreshed, or re-enforced when needed.

Why This Matters

This issue is required to make the identity model operationally safe over time.

It enables:

• targeted reverification after policy changes
• remediation of historically overridden users
• reverification after suspected identity issues
• controlled lifecycle resets without breaking the entire user base

Required Behavior

1. Admins can trigger reverification for targeted cohorts.
2. Cohorts can be selected using filters.
3. Historically manually overridden users do not auto-bypass a new reverification campaign.
4. Reverification campaign actions are auditable.
5. Users targeted by the campaign are returned to the appropriate verification-required state.

Acceptance Criteria

1. Admin can create a reverification campaign using filters.
2. A previously verified user can be forced back into verification flow.
3. A historically overridden user does not automatically bypass the new campaign.
4. Campaign targeting and execution are written to audit history.
5. Campaign execution can be tested against specific user subsets without impacting all members.

Suggested Filters

At minimum, support filtering by combinations such as:

• manually overridden users
• verified before date X
• verified after date X
• specific guild
• specific role or role set
• current lifecycle state
• explicit user list

Suggested Implementation Targets

• new admin command module under src/commands/admins
• src/services/PostgresDatabaseService.ts
• prisma/schema.prisma
• lifecycle transition application layer to be created or refactored

Suggested Technical Direction

Represent reverification as a first-class administrative action with:

• campaign metadata
• target filter definition
• execution audit trail
• resulting state transitions per targeted user

The write path must respect the same optimistic locking and lifecycle guards already defined elsewhere.

Validation

• unit test: campaign filter resolution selects intended users
• integration test: targeted user is returned to verification-required state
• integration test: historically overridden user does not bypass campaign
• integration test: campaign writes audit entries and transition metadata
• regression test: non-targeted users remain unchanged

Traceability

• Spec: docs/specs/issue-93-specification.md
• Matrix rules:
  • TRC-010
  • TRC-011
• Related docs:
  • docs/specs/traceability-matrix.md
  • docs/specs/issue-drafts.md
  • docs/specs/state-machine.md
  • docs/specs/bpmn-lifecycle.md

Related Issues

• Umbrella Epic - Feature List #93
• Implement global one-time verification identity across all DataDrop guilds #128
• Guard manual implicit verification to VerificationPending with mandatory email check #131
• Enforce strict optimistic locking with bounded retries for transition writes #132