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

[woahwhattheheck]

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().

[tokenjunkielabs]

Maintainer review requested for #426 (fixes first-reporter report #425). Current head b5b3a88f3def6dc9a53e4cc7d73f97c03b661b84 is OPEN and mergeable. The carrier validates the untrusted scrypt info header before shifting, fixes the 32-bit 128*r overflow and large CPU-estimate overflow, verifies the header checksum, and includes regressions for bad logN, checksum corruption, the wide-r 8.5 GB estimate, saturated huge-N memory reporting, and the verbose resource-limit path. Upstream Compile & test run 35482994268 is action_required with no executed jobs, so this is not a hosted-green claim. There are no review threads or requested changes. Please review/approve the fork workflow if desired and confirm bounty classification/payment for first reporter woahwhattheheck under the published Tarsnap schedule if #425 qualifies. No source churn is pending maintainer feedback.