scryptenc: validate the header parameters used by "scrypt info"

[woahwhattheheck]

Disclosure, per this repository's AGENTS.md: I am an LLM (Claude), submitting on behalf of the account owner. I am available to discuss this change and to revise it in response to review feedback.

Fixes #425.

scryptdec_file_printparams() — the scrypt info path — reads logN from
header[7] and passes it to display_params(), which computes
(uint64_t)(1) << logN. scryptdec_file_load_header() validates only the
magic and the version byte, so logN can be any value in [0, 255] and
anything >= 64 is an out-of-range shift. Every other caller of
display_params() bounds logN first (checkparams() rejects
logN < 1 || logN > 63; pickparams() never exceeds 63), so info is the
only way in — and the only one reached with untrusted input.

Commit 1 — reject out-of-range parameters in scrypt info

• Validate logN, r and p in scryptdec_file_printparams() using the same
  rules checkparams() uses, returning SCRYPT_EINVAL ("Input is not valid
  scrypt-encrypted block") otherwise.
• assert() the logN bound in display_params(), so the precondition the
  shift relies on is stated where the shift is.
• Compute 128 * r * N in 64-bit arithmetic. 128 * r is a uint32_t
  expression and wraps for r >= 2^25, which checkparams() permits — a
  header with r = 0x02000000 is currently reported as needing "0 B" of
  memory rather than 8.5 GB, and that one is reachable from scrypt dec -v
  as well, since display_params() runs before the limit checks. The product
  can still exceed UINT64_MAX, so it saturates rather than wrapping.
• Compute 4 * N * r * p / opps in floating point; accumulated in uint64_t
  it overflows for logN = 63.
• Add tests/11-info.sh — scrypt info had no test coverage at all — with a
  96-byte fixture that has a valid checksum and an out-of-range logN.

Commit 2 — verify the header checksum in scrypt info

scryptdec_setup() rejects a header whose SHA-256 checksum does not match;
scryptdec_file_printparams() never checked it, so scrypt info on a file
with a damaged header printed whatever N, r and p the damaged bytes
encoded and exited 0. This performs the same check.

This commit is separable from the first — the first fixes the undefined
behaviour on its own — so it can be dropped if you would rather info stay
purely descriptive. The test fixture's checksum is valid either way, so the
logN test still exercises the parameter check with this commit applied.

Notes

• No behaviour change for well-formed files: scrypt info on
  tests/verify-strings/test_scrypt_good.enc still prints
  N = 262144; r = 8; p = 1; and exits 0.
• Public API and file format are untouched; the only new failure mode is
  SCRYPT_EINVAL on a header that was already invalid.
• The assert() matches the existing one in scryptenc_setup().