sha512.c: the copy >> 61 carry term in eos_sha512_update() is always zero #121

Symptom

core/sha512.c, eos_sha512_update(): ctx->bitlen[0] += (uint64_t)copy >> 61; is always zero. copy is clamped to 128 - ctx->buffer_len, so copy <= 128 and copy >> 61 == 0 on every iteration. The real 128-bit carry is already handled by the old_low comparison two lines above.

Not a defect — the digest is correct (RFC 8032 vectors and the SHA-512 KATs pass) — but the line reads as overflow handling and does nothing, which is the kind of thing a future reader preserves because they assume it matters.

Raised in review of #115; left out of that PR deliberately so the file stayed a byte-exact restoration of the previously reviewed blob (d9aa57c).