pow, validation: report the condition that actually failed

[xanimo]

Thanks to @edtubbs for flagging the confusing output — the log line he posted is
what prompted this, and it turned out the diagnostic was the problem rather than
the validation.

check_pow printed a rejection reason that could not report two of its own four
failure conditions. One of the checks was (const uint8_t*)target == 0, which
tests whether the pointer is null rather than whether the target is zero, so it
was always false. The result was a log line that looked self-contradictory:
validation failing while every reported condition read as fine.

This evaluates each condition into a named local and prints all four, plus
nbits:

58:check_pow: nbits: 0x00000000 f_negative: 0 target_is_zero: 1 f_overflow: 0 above_pow_limit: 0
src/validation.c:104:check_auxpow : AUX proof of work failed

Which answers Ed's question empirically. nbits: 0x00000000 because those
synthetic cases hand the AuxPoW body straight to the deserializer with no 80-byte
header parse ahead of it, so header->bits is still zero from
dogecoin_auxpow_block_new(). A zero nBits decodes to a zero target, and a
zero target is correctly rejected. Not a regression — expected output from the
2026-06-23 negative-path tests, which were never wrong, only illegible.

Also drops four strerror(errno) calls from check_auxpow. errno is not set by
these failures, so it printed whatever happened to be left over — the : Success
suffix on a failure line comes from exactly that.

No functional change. Same code accepted, same code rejected; only the
reporting differs.

78/78.

Note: the same strerror(errno) pattern appears throughout block.c's
deserialize error paths. Same defect, larger diff, left for a separate change.

[xanimo]

Amended: short-circuit restored.

The first version hoisted arith_uint256_is_zero and uint256_cmp into locals ahead of the if. That reported all four conditions but evaluated uint256_cmp even when set_compact had already flagged the target as overflowed — defined behaviour and no functional difference, but there is no reason to compare a target that has already been rejected.

The condition is short-circuited again, with the individual terms computed inside the failure branch where the cost is irrelevant.

Also checked: errno.h is not included by pow.c or validation.c, so dropping the strerror(errno) calls left no unused include behind.

78/78, diagnostic output unchanged.

[edtubbs]

ACK, good to report all conditions on failure. The (const uint8_t*)target == 0 tested the wrong thing and dropping strerror(errno) makes sense since it's not set by these failures.