perf(queue): stop serializing every delivery on one mutex, and prune the tombstones nobody removed

[EvalAlan]

Delivery throughput was capped by two things inside the queue, not by the
network, the scanners or the mailbox server. Turning ClamAV off changed
nothing. Delivering to a sink fifty times faster than Dovecot changed nothing.
Both of those were the right experiments and both came back negative, which is
what finally pointed inward.

One mutex, held across disk I/O

Manager.DeleteMessage took the manager's single write lock and held it while
reading the message metadata, reading the entire message body, and writing a
tombstone plus unlinking two files. Every completed delivery in the server
queued behind it.

Measured on a 52,000-message queue with 20 workers configured:

LMTP operation	p50 33.5ms
workers actually busy	0.9 of 20
elemta / dovecot CPU	6.25% / 4.13%
drain rate	11/s

Nineteen workers blocked on a lock, on an idle machine.

Deletes of different messages touch different files and have never needed to
exclude each other; deletes of the same message do. The hot path now takes a
read lock plus a per-message-id lock. FlushQueue and Stop keep the write
lock and still exclude deletes entirely, and the storage backend's own per-id
lock and durable tombstone ordering are untouched beneath it. MoveMessage
gets the same treatment — a deferral has no reason to block a delivery
completing on another message.

200 concurrent deletes: 34.8ms → 10.5ms.

452,502 tombstones, 885MB, never pruned

Profiling a drain with no inbound traffic showed 19 goroutines runnable inside
atomicWriteReaderAt and 73% of CPU in syscalls — the delivery path was
writing files. /app/queue/tmp held 452,502 consumed-enqueue markers totalling
885MB, and nothing had ever removed them. The same unbounded growth the sqlite
and postgres backends had; this is the backend that was missed.

Cleanup now prunes them on their own age bound, independent of message
expiry, because they outnumber live messages by orders of magnitude.

The message body stays in the tombstone, and that is deliberate. Removing it
would roughly halve the write on every delivery — it is the single biggest
remaining cost — but TestNewTombstoneRemainsReadableByOldBinaries protects a
real failure: a binary rolled back to a build predating ContentHash reads only
that field, and an empty body would make it treat every retry as a conflict and
start refusing mail. That is a deployment decision about rollback range, not a
performance tweak, so the cost is written down rather than taken.

Also

• net/http/pprof on the metrics listener behind ELEMTA_PPROF=1, off by
  default — that port binds 0.0.0.0 and pprof serves goroutine stacks and a
  CPU profiler to anyone who can reach it.
• Queue sweep interval 10s → 1s. It is pickup latency, not throughput: gaps of
  exactly 10,005ms were measured between claim cycles, which is a queued
  message doing nothing.

Two bugs of mine, caught by testing rather than reading

The first pruner swallowed the unlink error, so failing to delete counted as
success. The second was subtler: os.DirEntry.Info() resolves its lstat against
the process working directory, and these directories are opened with openat
and wrapped by os.NewFile, so every stat failed and every entry was silently
skipped. It now stats relative to the descriptor, like the rest of that file.

Verified

Whole internal/queue package green under -race. The same message deleted
from twelve goroutines succeeds exactly once; 200 different messages do not
serialize; the lock map returns to empty; a stale tombstone is pruned while a
fresh one survives. Live: peak throughput 104/s → 136/s.