test(x25519): pin ConstantTimeEqual's acquisition order from outside the module

[deadpoets]

The core half of the ABBA fix (#65, secret.go) landed with a regression test
that observes the acquisition order directly. The crypto half landed bare.

The two obstacles are real but narrow: bufferRWLock is unexported, this
module builds against a released core tag, and no exported call holds an
exclusive lock long enough to watch the order the way core's test does. That
rules out lock observation and deadlock reproduction — not the property itself.

The invariant that regressed is "the first lock acquired is a function of the
pair's identity, not of argument position." This rigs it through exported API:

• the higher-addressed buffer gets a held reader plus a queued writer, so
  writer preference parks every new read acquire on it;
• the lower-addressed buffer is sealed, so a read acquire returns
  ErrSealed without running the nested callback.

Then ConstantTimeEqual is called with the higher-addressed key as the
receiver, so argument order and address order disagree:

	first acquire	outcome
ordered (fixed)	sealed, lower-addressed	fails fast, never touches the other — call returns
argument order (unfixed)	receiver, higher-addressed	parks behind the queued writer — call never returns

So "the call returns at all" is exactly the fixed ordering.

Verification

• Fails against the unfixed code with the intended message (ordering swap
  disabled via if false && …, keeping unsafe in use), and unwedges itself
  rather than hanging the run.
• Passes against the fix.
• Passes under GOWORK=off, i.e. against the released core tag rather than the
  workspace.
• go vet clean; full go test -race ./... green for the module.

Why no stress test

Reproducing the deadlock needs both goroutines paused between their two
acquires, and there is no hook to do that. The stress version written for core
passed just as happily against the broken code, which is why it was deleted
rather than kept for coverage optics.

Note for the next core release

Crypto orders by buffer address only because the janitor counter is
unexported. That is sound today — Go's collector is non-moving, and two live
buffers can never share an address, so both goroutines derive the same total
order — but it is an assumption worth retiring. The next core release is
already a MINOR bump (InstallTerminationWipeNoExit) and already forces a
crypto floor raise; exporting a stable buffer identity in that same bump lets
the floor-raise PR switch to the counter and delete the caveat at no extra
release.