feat(organization): support opt-in soft deletion for organization members

Problem

In multi-tenant SaaS applications, organization-owned historical data often needs to remain accessible after a member leaves or is removed.

For example, assets, audit events, billing records, and other organization resources may continue to reference the removed user's ID. However, organization.removeMember currently hard-deletes the member record.

Once that row is deleted, the application loses its authoritative record that the user was previously a member of the organization. This makes it difficult to:

• Display former members in historical resource filters.
• Resolve historical activity or ownership without inferring membership from domain tables.
• Preserve membership context for auditing and billing.
• Distinguish former members from unrelated users referenced by application data.

Deriving former members from assets or maintaining an application-specific shadow membership table duplicates Organization plugin state and can become inconsistent.

Proposed solution

Please consider adding opt-in soft deletion for Organization plugin members.

The exact API can follow the maintainers' preferred design. One possible shape would be:

organization({
  member: {
    softDelete: true,
  },
})

When enabled:

1. removeMember and leaveOrganization set deletedAt instead of physically deleting the member row.
2. Deleted members immediately lose all organization authorization.
3. Default membership lookups, permission checks, member lists, counts, invitations, and active-organization flows exclude deleted members.
4. A server-side API can explicitly query former members, for example through withDeleted or onlyDeleted.
5. Re-adding the same user restores the existing membership or otherwise handles the existing (userId, organizationId) unique constraint.
6. Updating roles or teams must not accidentally reactivate deleted memberships.
7. Applications can explicitly hard-delete or purge historical membership records when required.
8. The behavior of related team-membership records is defined when an organization member is soft-deleted or restored.

Relationship to existing work

Issue #9099 discusses soft deletion of user accounts:

https://github.com/better-auth/better-auth/issues/9099

PR #10005 introduces generic plugin/model-level soft-delete infrastructure:

https://github.com/better-auth/better-auth/pull/10005

This request is narrower: it asks the Organization plugin to opt its member model into that infrastructure, or expose an Organization plugin option that applications can enable.

If #10005 is the intended foundation, would the maintainers accept a follow-up PR adding opt-in soft deletion specifically for organization members?

Alternatives considered

• Maintain a separate former-member table in the application.
• Store former-member IDs in organization metadata.
• Derive former members from assets, audit events, or other domain records.
• Replace the Organization plugin's member-management flow with custom logic.

These approaches duplicate or infer membership state outside Better Auth and make the plugin less authoritative.

Additional context

The concrete use case is a PostgreSQL/Drizzle SaaS application where organization resources remain owned by the organization after their creator is removed.

Soft deletion should preserve historical membership identity only. It must not preserve access: removed members must stop passing authorization checks immediately.