…eted

Deleting an organization only soft deletes it: the row (and its permalink) is
kept until the hourly deletion task purges it. The web UI, however, hides it
immediately -- it disappears from the organization list, the header switcher
and every lookup (all scoped to `present`). That left an invisible squatter:
re-creating an organization with the same short name failed with "Short name
has already been taken" even though no conflicting organization was visible
anywhere, while the same name silently produced a suffixed permalink (acme-2).

Separate the two concerns so what the UI shows matches what the system
enforces:

  * Organization#soft_destroy releases the permalink (moves it to a unique
    `deleted-<uuid>` tombstone) before saving, so the short name is free again
    the moment deletion completes and can be reused immediately.
  * Permalink uniqueness and Organization.find_unique_permalink are scoped to
    present (deleted_at: nil), so deleted organizations can never block or
    perturb permalink generation again.
  * The delete page explains the behaviour: the organization and its short name
    go immediately; mail servers and data are purged in the background.
  * The purge task logs the organization name, since the permalink is a
    tombstone by the time that task runs.

Records are still retained until the background purge, so deleting stays
non-blocking, and stale deleted rows predating this change are ignored too.