fix: wipe constructor inputs on failure; close three wipe-guarantee overclaims

[deadpoets]

Four findings that share one shape: the code claimed to wipe more than it
did. One is a real behaviour bug; three are claims corrected to match reality,
with one of them made true instead.

1. Constructors wiped the input only on success — INFO, but the real bug here

securebuf.go:134. NewBuffer, NewSyscallSafeBuffer and NewSecret warn:

raw is zeroed after copying. The caller must not reuse raw after this call.

Every error path returned with the plaintext intact. A caller who believes
that warning does not wipe it themselves — so an allocation failure left the
secret sitting in an ordinary heap slice they had just been told was gone.

Verified against the unfixed code:

NewBuffer failed (VirtualLock: Insufficient quota…) and left
536870912/536870912 plaintext bytes in the caller's slice

Now deferred, so a future error path cannot forget it.

Consequence, stated: a retry after ErrNoSecureMemory has nothing left to
copy. It does not need one — that error depends only on a per-platform const
and WithInsecureFallback, both knowable before the call via Probe.

2. HKDF Extract ran outside the scrub window — MEDIUM

secmem-crypto/kdf.go:219. hkdf.New performs Extract —
PRK = HMAC(salt, secret) — and the PRK is key-equivalent for every byte
Expand goes on to produce. It was constructed before the secmem.ScrubErr
window that the function's own doc says wraps the derivation.

The single most sensitive intermediate was the one value the window did not
cover. Moved inside.

3. MarshalOpenSSHPrivateKey claimed copies it cannot reach — MEDIUM

secmem-crypto/ssh.go:107. "This copy, and every derived form below, is
wiped" was not true: ssh.MarshalPrivateKey builds its own intermediates
around the private key and hands back only the final slice, so those copies are
unreachable from this package and left to the GC. The comment now names its
limit.

One of them was removable. pem.EncodeToMemory grows a bytes.Buffer as it
writes, and every growth orphans an array holding a prefix of the
base64-encoded private key — unreachable and unwiped. Encoding into a
pre-grown buffer means exactly one array, which the existing defer wipes in
full.

4. Scrub's "nothing sensitive is on the abandoned copy" — LOW

scrub_legacy.go:26. The entry wipe orders the stack growth, but morestack
copies the whole stack — so the segment it abandons carries whatever the
caller already had on its stack, and returns to the stack pool unwiped and
unreachable from Go.

The claim holds only if the caller had nothing sensitive there, which is not the
situation this package exists for: a key in a local, or residue from an earlier
operation, is exactly what gets left behind. Now in the documented limits rather
than asserted away.

Also corrects the stale "a no-op on other architectures", untrue since
scrubframe_arm64.s landed.

Verification

• core + redact -race green; secmem-crypto build + -race under GOWORK=off.
• New test drives the constructor failure path through an allocation the lock
  budget refuses, and skips if the environment happens to allow it —
  inverting the repo's usual convention, since here an allocation that
  unexpectedly succeeds is the environment condition.
• gofmt clean.