fix: acquire both read locks in a fixed order in ConstantTimeEqual

[deadpoets]

Both two-buffer comparisons — Secret.ConstantTimeEqual (secret.go:91) and
X25519Key.ConstantTimeEqual (secmem-crypto/x25519.go:174) — took their read
locks in argument order, so a.ConstantTimeEqual(b) and
b.ConstantTimeEqual(a) running concurrently acquired them in opposite
directions.

Read locks are shared, so this only becomes a cycle once a writer is queued on
each buffer — which a writer-preferring lock makes routine, since a Destroy
or an emergency wipe is enough to queue one. Once wedged, both buffers are also
unreachable for Destroy and WipeAllSecrets: one reversed comparison takes
the emergency wipe down with it.

Both now acquire in a fixed global order.

Two different ordering keys, deliberately

Module	Key	Why
core	janitorKey	process-unique counter; assumes nothing about object placement
secmem-crypto	buffer address	the counter is unexported, and this module builds against a released core tag

Using the counter from crypto would have meant a core release plus a floor
raise before this deadlock could be fixed at all. Address ordering is sound
while the Go GC does not relocate heap objects — which it has never done — and
the comment says to switch if an exported identity ever lands.

What I could not test, and why I am not pretending otherwise

The deadlock itself is not what the test asserts. Reproducing it needs both
goroutines paused between their two acquires, and there is no hook to pause
them. I wrote the stress version first; it passed just as happily against the
unfixed code, which makes it worthless as a guard. It was deleted rather than
kept for the look of coverage.

The order is observable, and it is the property that makes the cycle
impossible. Holding an exclusive lock on the lower-keyed buffer and comparing
with the higher-keyed one as receiver puts argument order and key order in
conflict:

• ordered (fixed): blocks on the lower key, never read-locks the higher one;
• argument order (unfixed): read-locks the receiver first and holds it while
  blocked.

So a reader appearing on the higher-keyed buffer is the bug. Deterministic —
fails in 0.9s against the unfixed code, passes with the fix.

secmem-crypto has no equivalent test. bufferRWLock is unexported, so a
test in that module cannot observe which lock was taken, and nothing exported
holds a secmem buffer's exclusive lock long enough to arrange the conflict. That
is a consequence of crypto depending on released core API, and I would rather
state it than ship a stress test that proves nothing.

Verification

core + redact -race, secmem-crypto -race under GOWORK=off, gofmt clean.